Flightdeck

I built Flightdeck to give small containerized apps a repeatable path into AWS. An app supplies a Dockerfile and a small YAML manifest; reusable workflows handle validation, security checks, infrastructure, HTTPS routing, and promotion.

AWS Terraform ECS Fargate ECR GitHub Actions OIDC Trivy Checkov

View repository ↗ Read the specification ↗

## the problem

Generating an application is often faster than deciding how it should authenticate to AWS, store Terraform state, pass security checks, and move safely from development to production. I moved those decisions into one platform so each app does not need its own delivery design.

6m 38s fastest cold run

Measured from a plain-language app specification to a working public HTTPS URL.

short-lived AWS credentials

GitHub exchanges repository identity for a scoped per-app role through OIDC. There are no stored AWS keys.

same image in dev and prod

Production receives the exact digest tested in development instead of rebuilding from the release tag.

## see it running

Golf is a small application I use to exercise Flightdeck's delivery path. Changes merged to main deploy to development. A versioned release promotes the exact image already tested there into production without rebuilding it.

Open production ↗ Open development ↗

Both services scale to zero overnight to control cost. If a link is unavailable, the fleet status page can start it; startup usually takes about a minute.

## architecture

Flightdeck creates shared networking, routing, ECR, and GitHub OIDC once. Each app gets its own deployment role, Terraform state path, ECS service, logs, alarms, and DNS route.

## why I built it this way

ECS instead of Kubernetes

These are small HTTP services. ECS gives me scheduling and AWS integration without making cluster administration part of the app contract.

a contract before a portal

I started with a versioned YAML manifest and reusable workflows. That let me prove the platform boundary before adding another interface to maintain.

shared foundation, isolated apps

Apps share networking and routing to control cost, but each gets scoped identity and state. Releases promote the same tested image digest instead of rebuilding it.

## what I tested

the complete delivery path

I timed the path from an application specification to a public URL, including repository setup, image build, infrastructure, and deployment.

multiple application shapes

I deployed several independent apps through the same contract. That exposed reusable-platform problems a single sample app would have missed.

failure-driven hardening

Live deployments exposed missing replacement and cleanup permissions, overly broad OIDC trust, image-retention risk, and scaler error handling. I fixed those in the platform and added narrower controls or tests.

## boundaries and next steps

This is a reference platform for small HTTP services, not a general hosting platform. It currently assumes one container, one AWS region, cost-first task counts, and limited recovery automation.

Prove the full create, update, promotion, and destroy lifecycle with a disposable app
Add service monitoring and read-only Terraform drift reporting
Rehearse recovery and publish durable, sanitized evidence

View source ↗ Design specification ↗ Threat model ↗