Munim Ahmad L1F22BSCS0412
Mohammad L1F22BSCS0417
M. Haris Shakeel L1F22BSCS0434
Supervisor — Muhammad Asif Haroon · Group F25CS088
Final Year Project · Phase 4 — Defense
Liftoff
A Deploy-as-a-Service platform
Push once. Deploy anywhere.
$ git push origin main
✓ built & pushed to your registry
✓ live → my-app.ondigitalocean.app
Liftoff
one platform · your cloud
Pick a repo. Deploy.
your GitHub repo→
→
🌐live app
Connect once. Then just git push — Liftoff does the rest.
Two planes, one token
- TypeScript end-to-end · pnpm + Turborepo
- NestJS API + Next.js dashboard · Postgres + Redis
- Control plane (our SaaS) ↔ data plane (your DO)
The push-to-deploy pipeline
git push→ webhook, HMAC-verified- Build in GitHub Actions → user's DOCR
- Callback → Pulumi provisions in user's DO
- Patch App Platform → poll → live URL
11 states. Auto-rollback.
- Every deploy is a persisted state machine
- Existing stack? Patch image, skip provisioning
- On failure → auto-rollback to last-good image
Your secrets never enter our process
Pulumi runs as an isolated child process. Your decrypted DO token lives only in its environment — never in the API's memory.
- Per-tenant
Provider({ token })per run - Two BullMQ queues drive the work
Security as a first-class concern
- AES-256-GCM for tokens, secrets & vault values
- Webhooks verified by HMAC-SHA256
- JWT access + rotating refresh (HTTP-only)
- DO token validated — never returned or logged
A graph-native schema
- Services, resources & directed edges
- Edges drive automatic variable injection
- ~20 models · encrypted vars · soft-delete
A Railway-style live canvas
- Your environment as a live graph (React Flow)
- Draw an edge to wire Postgres → service
- Status animates live — no refresh
How the platform ships itself
- Control plane on Azure Container Apps
- One workflow: typecheck → test → deploy
- GitHub OIDC → managed identity, no stored secrets
- Tests gate the deploy
