Liftoff

Deploy-as-a-Service for your own cloud

Push code.
Get infrastructure.
Keep both.

Liftoff turns a git push into running services in your own cloud account. Your GitHub Actions build the images, your registry stores them, and Pulumi provisions the rest. If you ever leave, everything keeps running.

No build farm. No proxy registry. No hosted runtime.

acme/storefront
Deploy
GitHubacme/storefrontLiftoffcontrol plane✓ authorizedINTERNAL_API_URLDATABASE_URLauto-injectedwebnext.js · servicecpu 12% · mem 230Mi2 replicas · 0 restartsapinode · servicecpu 12% · mem 230Mi2 replicas · 0 restartsworkerqueue consumercpu 12% · mem 230Mi2 replicas · 0 restartspostgresmanaged · pg16cpu 12% · mem 230Mi2 replicas · 0 restarts
Connect a repositoryPreview diffApply

Built on stock cloud primitives

  • Zero-ops compute
  • Kubernetes
  • Managed Postgres
  • Managed cache
  • Object storage
  • Container registry

How it works

Repository to running app,
without leaving your account

01

Connect

GitHub and your cloud provider, both OAuth. Liftoff commits one workflow file to your repo. Nothing is provisioned yet.

02

Draw

Model services, data and connections on the canvas. The graph is the deploy spec — staged, then applied.

03

Push

Your Actions build one image per service — Dockerfile first, Nixpacks fallback — and push to your registry.

04

Deploy

Pulumi compiles the graph into your account. Migrations gate the rollout; status streams back live.

Platform

Everything an environment needs,
provisioned as one graph

A vault for variables

Environment- and service-scoped, plain or secret, build-time or runtime. Encrypted at rest; value changes apply without a rebuild.

DATABASE_URLruntime
STRIPE_SECRETsecret
VITE_API_BASEbuild

Bindings, not copy-paste

Connect a resource and its credentials resolve inside Pulumi, from live outputs. They never pass through Liftoff.

# resolved inside Pulumi, injected at runtime

DATABASE_URL=postgres://…postgres

REDIS_URL=rediss://…valkey

INTERNAL_API_URL=http://api:80service link

Gated migrations

Your pre-deploy command runs as its own job before traffic moves.

✓ job prisma migrate deploy 3.2s

● rollout web · api · worker

on failure: deploy stops, traffic untouched

Preview environments

Every pull request clones the environment. Close it, and it cleans up.

pr-42feat/checkoutlive
pr-38fix/navdestroyed

Two compute targets

The same graph deploys to either. Switch when you outgrow one.

App Platformzero ops
Managed Kubernetesyour knobs

Telemetry & rollbacks

Logs, metrics, uptime alerts and per-service rollback — streamed live over WebSocket.

cpu 42% · mem 512Mi · uptime 100%Rollback to #46

Service links across repos

One project, many repositories, one app. Internal URLs injected wherever an edge crosses.

webacme/storefront— INTERNAL_API_URL →apiacme/platform

Ownership

A control plane, not a landlord.

Liftoff orchestrates infrastructure it doesn't own — yours. The bill comes from your cloud provider, the resources answer to your token, and nothing about your app depends on Liftoff staying in the loop.

0
resources hosted by Liftoff
1
workflow file in your repo — removed on disconnect
100%
stock cloud primitives, plain Pulumi
DimensionLiftoffTypical PaaS
Compute runs inyour cloud accounttheir cloud, marked up
Images build onyour GitHub Actionstheir build farm
Images stored inyour container registrytheir registry
Database credentialsresolve inside Pulumi, in your accountpass through their control plane
When you leaveapps keep serving; Liftoff cleans itself outexport, rebuild, re-platform

Ready when you are.

Connect a repository, draw the graph, push.