Infrastructure automation

Encore automates application infrastructure from development to production, so new services and features can ship without Terraform PRs, provisioning tickets, or manual cloud setup.

Start building

See how it could work for your team.

Book a demo

Deploysproduction1v5dr0cb0mgc3je1e9k0

Retrigger

STATUSRunning

ENVIRONMENTproduction

STARTEDMay 25 at 16:06

DURATION1s

Build & testQueued

Provision infrastructure (1 change)Queued

Bucket ("receipts")Amazon S3 · versioning enabled

Pending

SQLDatabase ("orders")Amazon RDS · db.t4g.medium

Pending

Topic ("orders")SNS topic + SQS subscription

Pending

Provision logs6s

+2siam: created policy receipts-writer · least privilege

+4siam: granted s3:PutObject on receipts to orders

+6siam: no other service granted access

Deploy releaseQueued

Infrastructure from code

Encore’s open source Infra SDK replaces HCL/YAML with type-safe APIs for databases, pub/sub, object storage, secrets and caching. Declare one in your code and Encore provisions the managed service behind it.Configuration (instance sizes, regions, and so on) is set per environment in the platform instead of in the code, so the control is the same and there is less for coding agents to get wrong.Works locally without Docker configuration, and the same code deploys to AWS or GCP without changes.

~90%less infrastructure code

0configuration drift

Read the infrastructure SDK docs

todo/db.ts

import { SQLDatabase } from "encore.dev/storage/sqldb";

const db = new SQLDatabase("todo", {
  migrations: "./migrations",
});

Amazon RDS

Cloud SQL

Managed PostgreSQL with migrations, pooling and IAM auth

Your cloud account, your data

All infrastructure runs in your own AWS or GCP account. You have full access to the cloud console, can inspect any resource, and there's no vendor lock-in for your data.

Production-grade managed services: RDS, Cloud SQL, SNS/SQS, Pub/Sub, S3, Cloud Storage
Resources in your AWS/GCP account, with full console access
A dedicated IAM role with minimal permissions
Export and migrate anytime

Deploying to your own cloud

orders3 environments

EnvironmentsSettings

Infrastructure Resources Amazon Web Services

AWSprod-us-east-1 · us-east-1

1Fargate Service(3 services)

ECS Fargate ServiceAWS ComputeReady

AWSus-east-1

CONFIGURATIONEDIT

vCPUs2

Memory (MiB)4096

API GATEWAYS(1)

api-gateway

SERVICES(3)

1AWS RDS Instance(1 database)

4SNS Topics(3 subscriptions)

2S3 Buckets(versioning on)

0Unused Resources

Encore vs Terraform

Define infrastructure in your application code instead of separate configuration files.

Encore

3 lines of TypeScript

db.ts

import { SQLDatabase } from "encore.dev/storage/sqldb";

const db = new SQLDatabase("users", {
  migrations: "./migrations",
});

Networking, IAM, and secrets handled automatically

Terraform

50+ lines of HCL

main.tf

resource "aws_db_instance" "users" {
  identifier        = "users-db"
  engine            = "postgres"
  instance_class    = "db.t3.micro"
  allocated_storage = 20
  db_name           = "users"
  username          = var.db_username
  password          = var.db_password
  vpc_security_group_ids = [
    aws_security_group.rds.id
  ]
  # ... plus networking, IAM, secrets
}

+VPCs, subnets, security groups, IAM roles, secrets config, connection strings…

Code declares it, the platform configures it

Your code says which resources exist and how services use them. The platform holds everything environment-specific: instance sizing, connection limits, secret values, which cloud and region. The same code runs everywhere without a rebuild.

In your code

Committed, reviewed, same everywhere

Which resources existnew SQLDatabase("orders")

How services use themqueries, publishes, reads

Migrations./migrations

In the platform

Set per environment, no redeploy

Instance sizingdb.t3.medium → db.m5.large

Connection limits500 → 1000

Secret valuesper environment type

Cloud + regionAWS us-east-1 / GCP eu-west1

Encore reads the first and applies the second — so nothing environment-specific ends up hardcoded.