Laravel Hetzner Dns Api Laravel Package

Product Decisions This Supports

• Deployment and environment automation: Programmatically create/update DNS zones and records as part of release pipelines — provisioning preview environments (e.g., pr-1234.preview.example.com), promoting staging to production hostnames, and tearing down records on environment destruction. This is the strongest fit and the clearest "build vs. buy" win: a thin, MIT-licensed Laravel wrapper replaces hand-rolled Hetzner HTTP calls in deploy scripts and Artisan commands.
• DNS-as-code and configuration consistency: Treat DNS as a managed artifact owned by the application rather than manual dashboard edits. Enables drift detection (compare desired vs. actual records), repeatable environment cloning, and auditability of who changed what and when.
• Certificate and domain lifecycle workflows: Automating ACME/Let's Encrypt DNS-01 challenge records, or wiring record creation into domain-onboarding flows so a new customer domain becomes routable without a human in the loop.
• Multi-tenant and custom-domain products: If the roadmap includes customer-supplied domains (CNAME validation, TXT verification), this package is a plausible low-level primitive behind an internal abstraction — not as a direct dependency of product code.
• Build vs. buy: Buy (adopt) only as a narrow infrastructure adapter. It does not encode product logic, validation policy, approval gates, or rollback semantics — those remain product/engineering decisions and must be built in-house regardless.
• Roadmap caution — this is a blocking input: The repository is archived and last released 2024-04-15 (v1.0.1, a patch fixing HasBody/HasJsonBody request serialization). Adoption decisions must treat this as vendored/forked source under MIT, not a maintained dependency. That reframes the decision from "should we adopt this package?" to "should we absorb ~a few hundred lines of Saloon/Hetzner glue into our codebase?" — usually yes, if Hetzner is already our DNS provider; usually no, if we're selecting a DNS provider because of tooling maturity.

When to Consider This Package

Consider it when:

• Hetzner is already the committed DNS provider and switching cost is high.
• The stack is Laravel/PHP with Composer, and the team is comfortable owning a small forked dependency.
• Required scope is modest: zone and record CRUD, no complex bulk/batch semantics, no advanced traffic policies.
• The use case is internal automation (deployments, preview envs, cert challenges) with human-visible rollback and dry-run gates — not customer-facing self-serve DNS editing at scale.
• Legal/compliance favors MIT-licensed, self-contained code you can read end-to-end and vendor into the repo.

Look elsewhere when:

• Long-term support matters. An archived repo with 5 stars and a single-maintainer history is a maintenance liability. Prefer direct Hetzner API calls via the official HTTP contract, or a broader, actively maintained DNS abstraction (e.g., a multi-provider DNS library) if provider portability is a roadmap concern.
• You need guarantees on Laravel/PHP/Saloon version support. No published support matrix; the transitive Saloon dependency must be pinned and verified against your baseline — a real cost if you upgrade Laravel frequently.
• You require bulk operations, idempotency, retry/backoff, or rate-limit handling. The package is a thin wrapper; these are application responsibilities.
• DNS is business-critical with regulatory or SLA exposure. You need vendor-backed support, not community code.
• You're not on Laravel, or you want an HTTP-client-agnostic client.
• Provider lock-in is unacceptable. This package is Hetzner-specific; adopting it deepens that commitment.

How to Pitch It (Stakeholders)

For executives (30 seconds): "There's a small open-source library that lets our Laravel app manage DNS records automatically instead of engineers editing them by hand. It's MIT-licensed, so it's free and we can own the code outright. But the project is archived and unmaintained — so the honest framing is: we'd be adopting a few hundred lines of code we maintain ourselves, not signing up for a supported product. Recommendation: use it as a contained internal utility to automate deployment and preview-environment DNS if Hetzner is already our provider. Do not let it become a load-bearing dependency in customer-facing or revenue-critical paths. Expected effort: a short spike, an internal adapter, and tests — roughly one engineer-week, not a platform program."

For engineering:

• It's an infrastructure adapter, not domain logic. Wrap it behind our own DnsClient interface so we can swap to raw Hetzner calls or another provider without touching product code.
• Because upstream is archived, vendor/fork it into the monorepo and treat the MIT source as ours. Pin the Saloon transitive dependency and add integration tests for record create/update — the only notable upstream change (v1.0.1) altered request-body serialization (HasBody/HasJsonBody), which is exactly the path we'd rely on.
• Build in-house what the package deliberately omits: token storage/rotation and scoping, dry-run mode, structured audit logging of every DNS mutation, idempotent record upserts, and a rollback runbook.
• Sequence: confirm Hetzner operations we actually need → spike against a disposable zone → implement adapter + tests → non-production automation first → production behind approval gates.

Decision requested: Approve a bounded spike and internal-adapter approach for internal deployment automation only, with an explicit non-goal of customer-facing DNS management and a documented exit path to direct Hetzner API usage.