AWS installation
The formae agent runs in AWS on Amazon ECS Fargate. Three deployment shapes are documented:
- Bootstrap — recommended. A one-command, open-source installer that stands up the whole agent (VPC, ECS task, database) secure by default, as either a public HTTPS endpoint (your ACM certificate) or a private Tailscale-only endpoint. Automates what Standard ECS does by hand.
- ECS Express Mode — fastest quickstart for evaluation. AWS auto-provisions the ALB, target group, listener, security groups, log group, and metric alarms. Minimal commands, public endpoint, default VPC.
- Standard ECS — manual walkthrough for full control. You create the ECS Service yourself, run the agent in private subnets in a VPC of your choosing, and reach the API over VPN / bastion / Tailscale / PrivateLink.
All three run the agent on Fargate in production. The choice is how much is automated versus hand-controlled.
Which path?
Pick Bootstrap for most production installs — the fastest route to a secure, properly-networked agent (private subnets + NAT in tailnet mode, or a public ALB with your own certificate in alb mode) backed by direct PostgreSQL, without hand-writing the ECS service, security groups, and networking.
Pick Express Mode if you're evaluating formae, prototyping, or running a small or test environment. The agent is reachable on a public ALB — protect it with basic auth.
Pick Standard ECS when you need to hand-tune beyond what the bootstrap exposes:
- Custom networking (VPC peering, Transit Gateway, multi-AZ failover) or an existing VPC layout
- Fine-grained ECS controls, or integrating the agent into existing infrastructure-as-code
- You want to understand or customize exactly what the bootstrap automates
Compared
| Express Mode | Standard ECS | |
|---|---|---|
| Datastore | Aurora Serverless v2 + Data API (HTTPS) | Direct PostgreSQL (Aurora, RDS, or any) |
| Datastore scale ceiling | 1 MB request/response (Aurora Data API limit) | None |
| Networking | Auto-provisioned public ALB, default VPC | Private subnets in your VPC |
| CLI connectivity | Public ALB URL | VPN / bastion / Tailscale / PrivateLink |
| IAM roles | 3 (incl. ECS Infrastructure Role) | 2 |
| Resources auto-provisioned by AWS | ALB, TG, listener, SGs, log group, rollback alarm, ACM cert | None — you create them |
| Discovery filter | Two halves: AWS tags Express resources with AmazonECSManaged=true; you tag the rest with app=formae-agent |
One half: you tag everything with app=formae-agent |
| HA | Single task; ~30-60s outage during update | Same |
A note on agent placement
In production we recommend running the agent in a VPC separate from the resources it manages, with peering or Transit Gateway connecting them. Reasons:
- The agent's lifecycle is independent of the stacks it manages — a destroy+apply of a managed stack can't accidentally touch the agent's own infrastructure.
- Cleaner blast radius for IAM and networking policies.
- The agent's
discoveryFiltersconfig still excludes its own infra from discovery scans, but a separate VPC adds physical separation on top.
Express Mode puts the agent in the default VPC alongside other workloads — fine for getting started, less ideal long-term. The Standard ECS walkthrough sets the agent up in a separate VPC by default.
After install
- Operating the agent — custom images, Aurora rotation gotcha, backups, shell access. Applies to both modes. (Updates are per-method: see each walkthrough's own "Updating the agent" section.)
- Authentication — enable basic auth before exposing the agent.
- Observability — OTel export configuration.
- Local install — install the CLI on your laptop.