It's important to tell the readers how long you've been doing this - especially to those that also manage ADHD or ADHD-like symptoms.
Why? Because those individuals tend to spin something up, tell everyone about it (online, and offline) and then stop doing it few days later.
The result then ends up being a false signal for others in the same boat. People who read it, feel a spark of recognition ("someone like me actually figured this out"), and then invest real time, energy, maybe money, into replicating something the author themselves quietly abandoned two weeks later.
Just a small heads up from someone who used to get burned in the past :)
yeah we're seeing the same thing from the infrastructure side. small opinionated api surface means less code and you can actually read what the agent wrote.
yeah totally. an example from the article is that when when you're reviewing 31 lines of business logic instead of 150 lines of boilerplate it's a lot easier to catch bad error handling or security issues - which kinda goes hand in hand with what you're saying.
This is close to what we're doing with [Encore](https://encore.cloud). The framework parses your application code through static analysis at compile time to build a full graph of services, APIs, databases, queues, cron jobs, and their dependencies. It uses that graph to provision infrastructure, generate architecture diagrams, API docs, and wire up observability automatically.
The interesting side effect is that AI tools get this traversability for free. When business logic and infrastructure declarations live in the same code, an AI agent doesn't need a separate graph database or MCP tool to understand what a service depends on or what infrastructure it needs. It's all in the type signatures. The agent generates standard TypeScript or Go, and the framework handles everything from there to running in production.
Our users see this work really well with AI agents as the agent can scaffold a complete service with databases and pub/sub, and it's deployable immediately because the framework already understands what the code needs.
We've had a bunch of people migrate over from Heroku in the last couple years, especially after they killed the free tier.
The main difference from other alternatives is that you don't write any infrastructure config - you just declare what you need in your code (databases, cron jobs, pubsub, etc) and Encore handles provisioning it in your AWS/GCP account (works locally as well where local is 1:1 to your prod env). So there's no Terraform to maintain or Docker setup to mess with.
If you're looking to move off Heroku it's pretty straightforward, most folks get their app running in an afternoon. Happy to help if you run into anything: https://encore.cloud
Haha. We're not trying to replace Ops, just prevent teams from needing to build internal platforms before they can ship product. You can still modify all the provisioned infra directly in AWS/GCP console, or layer Terraform on top. We work alongside you, not against you.
Encore uses sensible defaults optimized for cost and performance (eg. reasonable instance sizes, log retention periods, backup schedules), but you have full control to modify anything. You can adjust configs per environment through the Encore Cloud dashboard or directly in your AWS console - it's all standard AWS resources (RDS, Fargate, etc.) in your account.
The goal is to start with good defaults so you don't have to think about every config detail upfront, but nothing is locked down. You can also set up approval workflows for any infrastructure changes that have cost implications before they're applied.
We provide client abstractions for infrastructure primitives (databases, pub/sub, object storage, etc.). Your application code uses these abstractions, and the actual infrastructure configuration is injected at runtime based on the environment.
For example, your code references "a Postgres database" and Encore provisions Cloud SQL on GCP or RDS on AWS, handling the provider-specific config automatically. The cloud-specific details stay out of your application code.
And if you prefer Kubernetes, we can provision and configure GKE or EKS instead of serverless compute. The point is your application code stays the same regardless.
Encore (the framework and CLI) is fully open source and free to use. You can deploy anywhere by generating Docker images with `encore build docker`.
Encore Cloud (optional managed platform) has a generous free tier and paid plans for production teams that want automatic infrastructure provisioning in their own AWS/GCP accounts. You can find more details at encore.cloud/pricing
You can just use the resource as you'd normally would and then use e.g. secrets to define the connection settings per environment. You would however need to provision the resource yourself for all your envs. We have a terraform plugin to help you automate it.
I'd argue it's the opposite of coupling. Your application code references logical resources (database connection, pub/sub topic, bucket) without knowing anything about the underlying infrastructure. Encore extracts these needs and a configurable planner transforms them into actual infrastructure.
The same application code can run locally (Docker), on AWS (RDS, SQS, Lambda), or GCP (Cloud SQL, Pub/Sub, Cloud Run) without changes. That's less coupling than explicitly configuring cloud-specific resources in Terraform or even using cloud SDKs directly.
Re: Chalice - similar idea but Chalice is AWS-only and focused on serverless functions. Encore is cloud-agnostic and works for any backend architecture (monoliths, microservices, containers, functions).
SST is AWS-specific and focuses on infrastructure-as-code for serverless apps (CDK wrapper). Encore is cloud-agnostic and works by parsing your application code to understand what infrastructure you need, then provisions it automatically on AWS, GCP, or locally. SST gives you more control over AWS-specific resources, Encore optimizes for development speed and portability. Different trade-offs depending on whether you're locked into AWS or want flexibility.
I haven't heard about Alchemy before, but from skimming their docs it looks like Terraform/Pulumi in code form where you explicitly configure infrastructure. Whereas with Encore, you define what you need directly in your application code (databases, pub/sub topics, cron jobs as type-safe objects), and Encore handles provisioning across all environments. Plus you get local development tools, distributed tracing, and automatic API documentation out of the box. The key difference is the toolbox you get + the fact that you're writing application logic, not infrastructure config.
1. You can configure your services to be cohosted on computes, and each environment can be configured independently. Encore also provides free hosting through Encore Cloud Hosting
2. The `encore run` command automatically starts local emulators for your infrastructure and starts the app as a single binary.
3. Encore uses static analysis to determine not only what infrastructure is used, but also what uses it. Based on these requirements we provision relevant VPCs, subnets, IAM Roles, SQL users, Security Groups etc. using best practices for each cloud provider. The specifics depend on how you configure each environment, and you can inspect all provisioned resources in your cloud console (and require approval for new cost-bearing infrastructure, and so on and so forth)
Different scope. NestJS organizes app code, Effect does functional composition - both still need separate infra tooling. Encore handles services + infrastructure + deployment as one thing. You could use Effect/NestJS patterns inside Encore apps though. Happy to answer specifics!
Good question! With Encore, your application code is actually more portable than with Terraform because you are defining infrastructure semantically (eg. "I need a Postgres database"), not with cloud-specific config. The same code deploys to AWS, GCP, or even locally with Docker so no Terraform rewrite is needed when switching clouds.
As for the language support; we support Go and TypeScript today. We're focusing on making these rock-solid first, but more languages are on the roadmap. Python is the likely next candidate.