Config is one file in your repo
Launchd
Railway
partial
Vercel
partial
Fly.io
—
AWS
—
Launchd takes a single config file and turns it into running infrastructure: containers, databases, queues, buckets, and background jobs. The file you run locally is the exact one we deploy in production.
We built infrastructure at NixLabs, and apps at SimpleLogic, and somewhere along the way we decided all existing tools sucked. So we built something better.
Every new project started the same way. Somebody disappears for a week setting up networking, IAM permissions, Terraform folders, registries, CI pipelines, secrets, and staging environments before a single feature ships. The rest of the team sits around waiting for infrastructure to exist. We kept rebuilding the same foundation over and over again and pretending that was normal.
Most teams end up with one setup for local development and a completely different one in production. Things work on your laptop, break in staging, then break differently in production. Docker compose files slowly turn into random scripts and undocumented setup steps nobody remembers. We wanted one file that behaves the same way everywhere so the environment stops being part of the problem.
Cloud invoices have turned into a joke. You deploy one app and suddenly you are paying separately for traffic, NAT gateways, logging, load balancers, storage operations, and ten other things nobody asked for. Half the time you do not even know what generated the charge. We wanted pricing that felt obvious. You should be able to look at your infrastructure and immediately understand what costs money and why.
A lot of platforms make migration painful on purpose. Custom runtimes, proprietary config formats, weird APIs, and features that only work inside their ecosystem. The longer you stay, the harder it gets to leave. We wanted to build around normal containers, standard networking, and boring infrastructure primitives so moving somewhere else later would not turn into a rewrite.
Railway, Vercel, Fly, and the big clouds all do good work, we used several of them ourselves, but we're a different shape. Here's what we mean by that.
Each primitive is the thing you'd reach for if you started over. Nothing here is a new query language, a proprietary protocol, or a mandatory SDK. If it looks boring, that's the point.
Bring a Dockerfile or point at a directory. We build, sign, and push. No registry to set up.
Managed, backed up, point-in-time recoverable. Reference the URL by name from any container.
Durable queues, scheduled jobs, and one-off workers — declared together. At-least-once delivery, DLQs, cron, retries.
Encryption at rest, lifecycle rules, signed URLs. Egress between your services is free.
One block routes traffic into your apps. Domains and certs auto-issued, JWT verification, per-route rate-limits, WAF.
Stored encrypted, mounted at boot — never baked into the image. Rotate keys, scope by environment, audit every read.
launchd dev spins up real services locally, actual databases, actual S3-compatible storage, actual queues.
Not mocks. Not stubs. Production reads the same HCL, runs the same containers, talks the same
protocols.
$ launchd dev → reading launchd.hcl ........................ ok → starting database main (postgres:16) .... ok 127.0.0.1:5432 → starting bucket uploads (minio) ........ ok 127.0.0.1:9000 → starting queue emails (nats) ........ ok 127.0.0.1:4222 → building container api (./api) ......... ok 4.1s → running api → http://localhost:8080 watching: ./api (12 files) database: postgres://launchd:dev@127.0.0.1:5432/main bucket: http://127.0.0.1:9000/uploads queue: nats://127.0.0.1:4222/emails [api] listening on :8080 [api] GET /health → 200 (3ms) [api] POST /upload → 201 (44ms, queued: emails) [api] worker picked up 1 message from emails
Postgres is Postgres. The bucket speaks S3. The queue speaks the same protocol production does. Your tests run against the real thing.
Edit, save, the container rebuilds incrementally. Migrations run in order. No daemon to restart, no terminal soup to manage.
launchd dev and launchd deploy read the same launchd.hcl. Local overrides — credentials, ports, fixtures — live in dev.hcl, gitignored by default.
launchd dev reset tears it all down. Snapshot the database first if you want; restore it later from any branch.
We generate the underlying docker-compose if you ask. You don't have to look at it. Most teams never do.
Every deploy goes through the same five stages, in the same order. If any stage fails, the previous version keeps serving traffic and the deploy reverts cleanly.
We watch the branch you tell us to watch. Or run launchd deploy from CI.
Read the file. Diff against live. Show what's about to change, line by line.
Reproducible OCI image, content-addressed, signed. SBOM included.
Schema diffs apply in a transaction. Roll back if any statement fails.
Health-checked. Old version keeps serving until the new one passes.
We picked boring primitives on purpose. Postgres is Postgres. Your buckets speak the S3 API. Your containers are OCI images. None of that is going to change because we changed pricing.
We'd rather earn the next month than trap you in this one. launchd export generates the equivalent docker compose for your stack. Run it any time, no support ticket
required.
Writes a plain docker-compose.yml and a terraform/ directory matching your HCL. Drop it into any host. We don't track when you do this.
pg_dump for the database. aws s3 sync for the bucket. We give you signed credentials and a checksum manifest. Nothing proprietary.
Every container image lives in your account's OCI registry. docker pull, push to wherever you're going. They were always yours.
Launchd started with two dreamers in Nashville and a small team across timezones. We grew up building software out of our bedrooms, teaching ourselves servers and infrastructure along the way. After watching every simple app turn into a cloud engineering project, we decided to build the platform we wished existed.
Our vision is small on purpose: be the boring, dependable layer between a developer's
laptop and the internet. Boring like Postgres is boring. We don't think the world needs
another opinionated framework. We think it needs fewer of them.
(see here)
We're funded by people who agreed not to push us toward enterprise sprawl. The plan is a real free tier, transparent pricing, and a code that stays OSS for as long as the company exists.
Director of day-to-day business operations.
Vision of the company, directs infrastructure
Leads development of our entire software stack
Built our platform with his bare hands
We're sending invites in small batches while we shake out the rough edges. Tell us a little about what you're building and we'll get you in as soon as it makes sense.
We don't have a marketing sequence. You'll hear from us once when there's an invite, and probably never again unless you ask.