Hetzner Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for a Hetzner control plane. If your roadmap includes provisioning, resizing, or tearing down Hetzner servers, networks, or load balancers from inside a Laravel app, this package is the "buy" answer to roughly 1–3 weeks of SDK work (auth, retries, pagination, typed DTOs, error mapping). Your decision shifts from "do we write API glue?" to "what product feature do we build on top of it?"
• Self-service infrastructure for internal or customer-facing users. An admin panel (Filament/Nova) or customer dashboard that spins up a server, attaches a floating IP, or points a DNS record at a tenant subdomain becomes a feature sprint rather than a platform project. That unlocks pricing decisions: do you resell managed hosting, charge for "bring your own Hetzner token," or keep it internal-only?
• Ephemeral / preview environments. Per-PR or per-demo environments are a classic Hetzner use case (cheap hourly billing). This package makes the create-destroy lifecycle callable from Laravel jobs and CI-adjacent tooling, which supports a concrete roadmap item ("review apps") without new headcount.
• Cost and EU-sovereignty positioning. Hetzner is materially cheaper than hyperscalers and EU-hosted. If a segment of your market cares about GDPR/data residency or margin per tenant, programmatic Hetzner control is a lever on both COGS and a sales objection — provided the SDK keeps the vendor swappable.
• Multi-tenant DNS and traffic routing. DNS records and load balancer management as first-class typed calls support product decisions like custom domains per tenant, blue/green cutovers, and regional failover — features that are usually blocked on "we don't have a clean way to touch DNS from the app."
• Scope negotiation with engineering. Because it is a thin, Laravel-native wrapper, it clarifies what is not solved: state reconciliation, drift detection, and declarative infrastructure remain Terraform/Pulumi territory. Use that boundary to keep "we'll manage infra from the app" from quietly becoming a homegrown IaC project.

When to Consider This Package

Adopt when most of these hold:

• You are a Laravel/PHP shop already on (or committed to) Hetzner Cloud, not evaluating clouds.
• You need imperative, runtime control — create/destroy in response to user action or jobs — rather than declarative desired-state management.
• You value Laravel idioms (config, DI, facades, test fakes) and typed responses over hand-rolled Guzzle calls.
• You can tolerate early-adopter risk: ~91 stars, zero dependents, small maintainer surface. Assume you may fork it (MIT permits this) and budget a small ongoing maintenance line.

Look elsewhere when:

• You need multi-cloud or multi-provider abstraction — put Terraform, Pulumi, or Crossplane in that layer and call Hetzner through it.
• You require state, drift detection, and auditable declarative infra — an SDK is the wrong primitive.
• Your stack is not PHP/Laravel, or you're on a long-lived platform where a vendor-supported SDK or the official OpenAPI spec plus a generated client is a better bet.
• The resource you need isn't covered yet (check the surface against your roadmap; "and more" is not a commitment).
• You need enterprise support SLAs, security review artifacts, or a named maintainer — a single-author MIT package will not clear procurement without you owning it.
• You're at a scale where orchestration belongs in Kubernetes/Cluster API, not application code.

Practical adoption guardrail: wrap it behind your own CloudProvider interface and pin the version, so the SDK is a detail, not an architecture.

How to Pitch It (Stakeholders)

For executives: This is a small, free (MIT) Laravel library that lets our application talk to Hetzner Cloud directly — creating servers, managing DNS, networks, and load balancers. It converts infrastructure work we would otherwise build ourselves into a product feature we can ship in weeks. It supports two business levers: lower hosting cost per tenant (Hetzner pricing) and EU data residency as a sales differentiator. The risk is concentrated and cheap to contain — it's a thin wrapper, MIT-licensed, so we can fork or replace it without re-architecting. It does not replace our infrastructure-as-code practice; it complements it.

For engineering: Type-safe, Laravel-native client — config, DI, and testable fakes instead of bespoke HTTP plumbing. It saves roughly 1–3 weeks of client-building and gives us typed DTOs and consistent error handling on day one. Two caveats: it has ~91 stars and no downstream dependents, so treat it as an early-adopter dependency — pin the version, keep it behind our own adapter interface, and expect to own a fork. And it is imperative only: no state, no drift detection. Terraform still owns declarative infra; this owns runtime actions. If that boundary is clear, it's a straightforward win.