- Is metaregistrar/php-epp-client compatible with Laravel?
- It is compatible in the sense that any Composer package is, but it is not Laravel-aware. It ships no service provider, facade, publishable config, or queue integration, so you must wrap it yourself. Treat it as a low-level protocol adapter behind a domain-provisioning port rather than a drop-in Laravel feature.
- How do I install metaregistrar/php-epp-client in a Laravel application?
- Install it with Composer and expect no package auto-discovery, because there is no Laravel service provider. Create a small RegistryClientFactory or singleton binding that resolves a configured client per TLD using credentials from config/registry.php and environment variables. Keep the client behind your own interface so you can swap or vendor it later.
- Can I use this EPP client directly in Laravel HTTP controllers?
- You can call it from a controller, but its connection model expects a TCP/TLS session and does not map cleanly onto PHP-FPM's request/response lifecycle. Push EPP traffic onto queue workers where connections are short-lived and explicit. The HTTP layer should record intent and dispatch a job, not hold a registry socket open.
- Which TLDs and registry extensions does metaregistrar/php-epp-client support?
- It implements base EPP plus a set of registry-specific extension objects, but coverage across registries is uneven. EPP is an RFC base with a long tail of extensions such as fee extensions, SIDN/.nl, Nominet, and CentralNic requirements. Treat each new TLD as a spike and verify extension support before committing to it.
- How should I store EPP registry credentials and client certificates in Laravel?
- Keep per-TLD host, port, username, password, client certificate path, and allowlisted egress IP in config/registry.php backed by environment variables. Never commit certificates or credentials, and plan for certificate and IP-allowlist rotation as an operational task. The package has no credential management, so this is entirely your wrapper's responsibility.
- Is metaregistrar/php-epp-client actively maintained and production-ready?
- It has roughly 238 stars and a single-maintainer profile, so treat it as a thin dependency with concentration risk. Verify the reported last release date of 2026-07-10 before citing it as evidence of active maintenance. Assume you may need to fork or vendor the package, and budget for reading its source.
- How do I handle EPP timeouts and ambiguous failures with this client?
- EPP failures are frequently ambiguous, such as a timeout after a command was sent, so reconciliation is safer than blind retry. Persist a domain_operations row with an idempotency key, TLD, command, payload hash, EPP transaction ID, and state before dispatch. Have the job write the registry response back verbatim so you can compare state and decide whether to retry or reconcile.
- How can I test EPP integration without hitting production registries?
- Use OT&E or sandbox accounts from each registry and build a test harness around your wrapper. Budget roughly one to two sprints for the wrapper, configuration, credential storage, and tests. Never let the first integration test hit production credentials.
- What is the best way to structure a Laravel job that provisions a domain via EPP?
- Create a ProvisionDomainJob that owns connect, login, command, and logout inside a try/finally block. Persist the operation record before dispatch and write the raw registry response back to it afterward. This keeps the socket lifecycle explicit on a queue worker and makes the integration debuggable.
- Are there Laravel alternatives to metaregistrar/php-epp-client?
- There is no Laravel-native EPP package in this context; the realistic choice is wrapping a protocol client or building a narrow one yourself. metaregistrar/php-epp-client is a framework-agnostic adapter, so put it behind a domain-provisioning port and compare alternatives by registry extension coverage. If you need many TLDs, evaluate coverage per registry rather than package popularity.