Build your product.

Not the three Lambdas talking to each other. Not the deployment you've been debugging since Thursday. Not the background job server you stood up for one cron job. The actual product. Launchd handles the rest.

Get early access → Sound familiar?

Database Functions Storage Queues Workers Auth Local dev Observability Rollbacks

The problem

You're shipping infrastructure instead of your product.

Every week something pulls you away from building. It's rarely a hard problem. Just an unsolved one.

A background job that needed a whole server.

You needed to run a task every night. Firebase had no cron. Supabase had pg_cron buried in the docs, with a note that it might not fire. So you spun up a $5 VPS for one job and left it running for eight months because you forgot it was there.

A queue built out of a database table.

Firebase had no queue. Someone on Stack Overflow said just poll a collection. You did. It worked until two workers grabbed the same document, ran the same job twice, and you spent a Saturday reversing the damage and learning what idempotency means the hard way.

One Lambda that turned into five.

Process a file on upload. The edge function timed out, so you added a Lambda. Then you needed another. Then they had to talk. Then you needed SQS. Three weeks later you were running a distributed system with no local dev story and hadn't shipped a single feature.

A bug that only showed up in production.

The local emulator behaved differently. The staging stack had a version mismatch. You pushed anyway. A customer found it in thirty seconds. You hotfixed it live, no rollback, just a prayer the migration didn't break anything else.

None of it was hard. Just unsolved. Your app was real enough to need real infrastructure, and small enough that nobody had built the right tool for it.

Launchd is that tool.

The gap

Simple platforms hit a ceiling.
Enterprise tools start at the ceiling.

There's always been a missing middle. Real infrastructure for teams that are too small for a platform engineer but too serious for demo tools.

Simple platforms

Firebase, Supabase

Good for getting started
Hit a ceiling fast
No background workers
No real queue primitives
Local dev is missing or broken
Works until it doesn't

Launchd

Built for the gap

Starts simple, grows with you
Full-featured from day one
Background workers built in
Real durable queues
Local dev identical to prod
One command to ship

Enterprise cloud

AWS, GCP, Azure

Infinitely capable
Starts overwhelming
Everything exists, nothing connects
Requires a platform engineer
Months to configure correctly
Billing before you ship

What's included

One platform.
Everything works together.

Not services you wire up. One config file. The pieces talk to each other because we built them that way.

Get early access →

Database

Real Postgres.

Replicas, failover, pooling. One connection string. Already connected to everything else.

Functions

Edge handlers.

Write the logic, not the server. Runs close to your users with no CDN to configure.

Storage

File uploads, handled.

CDN included. Use ours or bring your own S3 bucket. Either way, it just works.

Queues

Durable messaging.

At-least-once delivery, retry, dead-letter queues. No polling a database table.

Workers

Background jobs, built in.

Scheduled or event-driven. No cron server to manage, no forgotten VPS.

Auth

JWT, magic links, social login. Doesn't reach into the rest of your codebase.

Developer experience

Write. Run. Ship.

launchd dev starts your full stack in seconds. launchd deploy ships it globally. That's the whole workflow.

launchd deploy

apply stream live

→ provisioning db/main
→ running 2 migrations
→ warming api routes
→ binding queue/events
✓ stable in 3 regions

drift guard clean

policy no public db
policy queues require dlq
policy secrets stay server-side
pass deploy can proceed

01 / Write One file. Your APIs, your data, your jobs. That's the whole stack.

02 / Run launchd dev. Full stack locally, hot reload, nothing to configure.

03 / Ship launchd deploy. Done. Go back to building.

Local dev

Your whole stack on your laptop.

launchd dev boots everything in seconds. Change a file, it reloads. Not an emulator. The actual stack.

✓ Hot reload on every save

✓ Postgres with auto-migrations

✓ Queues run in-process, no emulator

✓ Pull secrets with launchd env pull

✓ Identical to production. Not an approximation.

launchd dev

$ launchd dev
◆ booting local stack from index.ts
├─ postgres  ready  localhost:5432
├─ queue     ready  in-process
├─ storage   ready  localhost:9000
└─ api       ready  localhost:3000

watching  src/  schema.sql  launchd.toml

  GET  /api/users/123      4ms
  POST /api/upload         12ms
↺ schema.sql changed → applying migration
✓ add_plan_column  applied in 38ms
  GET  /api/users/123      3ms

What makes it different

Built for how you actually work.

Not designed to impress enterprise architects. Built to get a solo developer or small team from idea to shipped as fast as possible.

Local dev

Your whole stack runs locally.

Not just the API. Database, queues, and workers all run in-process with hot reload. Identical to production, not an approximation of it.

Deployment

One command to ship.

launchd deploy reads your config, provisions what changed, and ships globally. No Terraform. No Kubernetes. No 3am config archaeology.

Integration

Everything is already connected.

Your functions can query the database, enqueue jobs, and write to storage. No wiring required. It works because we built it that way.

Scale

Built to grow with you.

Start solo. Add a teammate. Scale to millions of users. No migration, no upgrade, no re-architecture when you get traction.

Observability

Know before your users do.

Logs, traces, and metrics for every request and background job. Already on. No Datadog bill, no setup, no missing context when something breaks.

Recovery

Ship with a safety net.

Immutable deploys. One command to roll back to the last known-good state. Traffic switches in under ten seconds.

Why we built this

We were you.

We were building SimpleLogic, an app company. Good team. Real ideas. We thought that was the hard part.

It wasn't. Week after week something pulled us off the product. A service that needed wiring up. A deployment that worked locally and broke in staging for reasons that took a full day to track down. Config files. More config files. We kept telling ourselves we'd clean it up later.

Later kept moving.

The thing that really got under our skin: we knew better. At NixLabs we had built real infrastructure from scratch. Physical machines, custom networking, BGP. We knew what good looked like from the inside. What we were dealing with at SimpleLogic wasn't a hard problem. It was an unsolved one.

So we stopped building the app. We shut it down and started on the platform we should have had from day one. Not a side project. A real company, with enough scar tissue to know what right actually looks like.

The team

We've been the customer.

Apps at SimpleLogic. Infrastructure at NixLabs. We've been on both sides of this problem long enough to know exactly what it needed.

Owen Rummage

Chief Executive Officer

Keeps the company pointed at the user's problem, not the product.

Jarrett Harper

Chief Operations Officer

Keeps the company moving and makes sure everything stays organized.

Nova Clement

Chief Technology Officer

Leads platform engineering and keeps the developer experience honest.

Michael Garofalo

VP of Infrastructure Design

Ethan Mitchell

VP of Infrastructure Operations

Clair Delafuente

Systems Engineer

Trevor Janssen

Network Architect

Xavier Dillinger

Platform Engineer

Aidan Finnegan

Software & Systems Engineer

How we think

Small teams make great software.

The most important software in the world was built by small groups of people who cared about the problem. They shipped fast, stayed close to their users, and built things that mattered.

The thing that kills that momentum isn't the hard problems. It's the overhead around them. Infrastructure you didn't ask to manage. Platforms that stop scaling before you do. Hours spent on things that should just work.

We build Launchd to protect that momentum.

Start with how it should feel.

We decide the experience first, then build backward. The workflow is the spec.

Build what doesn't exist yet.

Sometimes the right tool isn't there. So we build it. That's how we got a local dev runtime identical to production.

If it needs a tutorial, it's wrong.

You should be able to use it right on the first try. If you can't, that's our problem to fix.

Not a Supabase clone

One platform. One runtime. No service sprawl.

Launchd is built so your API, database, storage, queues, workers, cron jobs, deploys, and observability live in one place. No stitching five vendors together. No sidecar servers. No "just one more service."

Without Launchd

Platform by patchwork

Auth in one product. Queue in another. Cron on a VPS. Logging somewhere else. It ships, then it drifts.

With Launchd

One service to run your product

One config. One deploy command. One place to operate your backend from first user to real scale.

FAQ

Questions you should ask before trusting a backend platform.

Is this just another Supabase clone?

No. Supabase is a DB-first product with add-ons around it. Launchd is an integrated runtime where the services are designed to work together by default, so you don't assemble your own platform.

Do I still need other services for core backend features?

For core backend workloads, no. Launchd includes compute, Postgres, storage, queues, workers, cron, deploys, logs, metrics, and rollbacks in one system.

What happens when I outgrow the "starter" phase?

You don't re-platform. The same stack scales with replicas, queue throughput, multi-region deploys, and production controls without rewriting your app around a new architecture.

Can I run everything locally and trust it matches production?

Yes. launchd dev runs the same primitives locally so your dev environment behaves like production instead of a partial emulator.

How fast can a small team ship on this?

The model is simple: define the stack once, build features, deploy with one command. You spend engineering time on product behavior, not platform wiring.

Is this locked down to one way of building?

No. You can keep your app architecture and workflows. Launchd's opinion is on platform operations: integrated defaults, reliable primitives, and less glue code.

Get early access

You should be writing
product code.

Launchd is in private beta. Leave your info and we'll reach out when it's ready. No updates, no newsletter. Just the one email that matters.