Encore.dev Promises No Terraform — Until You Self-Host

Encore.dev's pitch sounds like it eliminates a whole job function: declare a Postgres database and a Pub/Sub topic in your application code, run encore run, and real infrastructure spins up on your laptop — no Docker Compose file, no hand-written Terraform module. Deploy to Encore Cloud and the same declarations provision an actual RDS instance and an actual SNS topic in your own AWS account. No plan, no apply, no HCL.

That claim holds up — as long as you keep paying Encore Cloud to make it true. The moment a team self-hosts the exact same application, using Encore's own open-source, MPL-2.0-licensed framework, the automation stops at the Docker image. Provisioning the database is back to being the team's job. Below is what "Infrastructure from Code" actually automates, the specific command where that automation ends, and what it costs on the tier where it doesn't.

What Infrastructure-From-Code Actually Automates​

Encore's framework (available for Go and TypeScript) lets a service declare the infrastructure it needs as regular application code instead of a separate config format. A Pub/Sub topic in TypeScript looks like this:

import { Topic } from "encore.dev/pubsub";
 
export interface SignupEvent {
  userID: string;
  email: string;
}
 
export const signups = new Topic<SignupEvent>("signups", {
  deliveryGuarantee: "at-least-once",
});

A database declaration is similarly plain — new SQLDatabase("users", { migrations: "./migrations" }) — and a cron job is a schedule string attached to an endpoint. Running encore run locally spins up real Postgres and real Pub/Sub semantics on the developer's machine, not a mocked approximation.

The part that actually replaces Terraform happens on deploy. According to Encore's own comparison, when the app ships to Encore Cloud, the platform reads those same declarations and calls the AWS or GCP API directly — provisioning real RDS plus SNS/SQS, or Cloud SQL plus GCP Pub/Sub, inside the team's own cloud account. There's no separate state file to reconcile and no HCL to context-switch into; the infrastructure is, in Encore's framing, "always a function of the code." The company's own argument for why this matters leans on the same AI-agent shift reshaping deploy tooling more broadly: "when an agent generates ten new endpoints in an afternoon, nobody writes the ten Terraform modules to match."

That's a real capability, and it's aimed at a real gap. Encore explicitly positions itself as "not a BaaS" — unlike Supabase or Firebase, it isn't a shared multi-tenant runtime a team's data lives inside. The infrastructure lands in the team's own AWS or GCP account, with native billing and no shared failure domain. For a team that has already decided it's staying on a hyperscaler and wants type-safe provisioning instead of a hand-rolled Terraform module per service, that's a genuine trade worth taking.

Encore is a small, credible bet on that specific problem rather than a hobby project: it's built by engineers who previously worked on backend infrastructure at Spotify and Google, its core framework carries 12,000+ GitHub stars under the MPL-2.0 license, and it's explicitly aimed at the team that has outgrown a Supabase- or Firebase-style BaaS — a category Supabase itself dwarfs on raw community size (over 100,000 stars), because the two tools aren't actually competing for the same decision. Supabase asks a team to move its data into Supabase's runtime; Encore asks a team to keep writing backend code and let a framework wire that code to infrastructure the team already owns the cloud account for.

The Automation Stops the Moment You Self-Host​

Here's the part the "no Terraform" framing skips over. Encore's local framework, parser, compiler, and CLI are fully open source, and self-hosting is a documented, first-class path: encore build docker produces a portable Docker image of the compiled application that runs on any provider, no Encore Cloud account required.

But building that image is not the same as provisioning what it needs. Encore's own self-host configuration docs are explicit that a self-hosted deployment requires a separate infrastructure config file, supplied at build time:

encore build docker --config path/to/infra-config.json MY-IMAGE:TAG

That file has to describe infrastructure that already exists — "provisioned via Terraform, Pulumi, or any other tool," in Encore's own words — before the app can start. For every SQLDatabase declared in code, the config needs a matching entry pointing at a real, already-running database:

{
  "sql_servers": [
    {
      "host": "db.myencoreapp.com:5432",
      "databases": {
        "main_db": {
          "username": "db_user",
          "password": { "$env": "DB_PASSWORD" }
        }
      }
    }
  ]
}

Pub/Sub works the same way — the config names an existing GCP Pub/Sub project and topic, or an equivalent AWS resource, that the team stood up beforehand. Nothing in the self-hosted path calls a cloud provider's API on the app's behalf. The "from code" half of the pitch — the part where declaring a database in TypeScript makes the database exist — is specifically an Encore Cloud feature, sold separately from the open-source framework that makes the rest of the pitch (type-safe declarations, local dev parity, no config-format context switch) true for free.

Reinforcing where the line sits: Encore Cloud's automated provisioning currently covers AWS and GCP only, with Azure "on the roadmap" and no automated path to Hetzner, DigitalOcean, or a bare-metal Kubernetes cluster at all. A team self-hosting on any of those still writes the Terraform module Encore's marketing says it eliminated — they just write it once, outside Encore's tooling, instead of per-service inside it.

What the Automation Actually Costs When You Do Pay For It​

Encore's pricing page lists a free tier (two dev environments, 1M tracing events/month) and a Pro tier priced across three separate meters: $49 per member per month, plus $99 per AWS/GCP environment per month, plus $2.5 per month for every "resource" in each environment — where Encore defines a resource as any code-level abstraction the app declares: services, databases, cron jobs, caches, buckets, Pub/Sub topics and subscriptions, and secrets, each counted individually.

Put a realistic small backend on that meter. A 3-person team running staging and production, with an app that declares 2 services, 2 databases, 1 Pub/Sub topic plus 1 subscription, 2 cron jobs, and 2 secrets — 10 billable resources per environment:

That $395 is the control-plane fee for automated provisioning — it doesn't include the actual RDS instance, SNS traffic, or EC2/Fargate compute the provisioned resources run on underneath, which AWS bills separately on top. The same topology, run on an owned Hetzner box behind a Cluster-API-managed fleet, has no per-seat, per-environment, or per-resource line at all — the flat hardware cost is the whole bill, and adding a fourth team member or a third cron job doesn't move it.

Where Encore's Bet and a Cluster-API PaaS's Own-Machine Bet Actually Diverge​

Both answers start from the same complaint — hand-wiring Postgres, Pub/Sub, and cron for every new service is real, repeated toil — and both explicitly reject the BaaS answer (Supabase, Firebase) of moving the app's data into a vendor's shared runtime. Past that point they solve for different things.

Encore's bet is that a team wants to stay on AWS or GCP — keep the native RDS instance, the native SNS topic, the IAM policies and compliance posture a hyperscaler account already has — and just wants the provisioning step automated and type-checked against the code that depends on it. That's a real, delivered capability, and it's worth the metered price for a team that has already committed to living inside a hyperscaler account.

A Cluster-API-managed PaaS on owned Hetzner hardware is answering a different question: not "automate my AWS account," but "remove the AWS account, its bill, and its dependency entirely." There's no native RDS to call into on owned hardware — Postgres runs as a workload on the fleet like any other service, not a distinct managed product — so a team that specifically wants a hyperscaler's managed-database SLA has a real reason to prefer Encore's model over this one. But there's also no per-seat, per-environment, or per-resource meter running underneath it, and no cloud account whose billing team, IAM policy, or outage the platform inherits.

Neither is a strictly better version of the other. "Infrastructure from code" targeting a team's own hyperscaler account and "infrastructure the platform already owns, with no account to meter" are two different answers to "stop hand-wiring infrastructure" — a team choosing between them is really choosing whether the destination is still a cloud account at all, not just which tool automates getting there.

The practical test is which dependency a team is actually trying to shed. A team that's fine staying on AWS or GCP indefinitely, and just wants the provisioning boilerplate gone, gets exactly that from Encore Cloud's metered automation — real infrastructure, real type safety, at a real per-seat-and-per-resource price. A team whose actual complaint is the hyperscaler account itself — its bill, its IAM sprawl, its outages, its own vendor risk — hasn't solved that problem no matter how automated the path into that same account becomes. That team is asking a question Encore's own product isn't built to answer, and a Cluster-API fleet on owned hardware is.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with no hyperscaler account, per-resource meter, or seat fee standing between a deploy and the bill. Star the repo on GitHub or deploy your first app today.

Sources​

• Encore Blog: What is Infrastructure from Code?.
• Encore Docs: Encore compared to Supabase / Firebase.
• Encore Docs: Build Docker Images (self-host).
• Encore Docs: Configure Infrastructure (self-host).
• Encore Cloud Pricing.
• Encore Blog: Encore is now fully Open Source.
• encoredev/encore on GitHub.