That's for request handling overhead. Real-world speedup depends on your bottleneck (DB, external APIs, etc.), but the gains still apply. Good feedback though, and we have more benchmarks planned regardless.

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.

How could it even achieve that? GCP and AWS don’t follow some higher standardized setup. If you use GCP app engine nothing exactly like it exists in AWS, not to mention even similar services like s3 have totally different configs and behaviors.

If I really cared about that I would just use k8s instead of hoping an infra as code tool mapped all these services somehow.

That's the orm argument. "If I need to switch DBs..."

In practice, that is not really viable and should not be a motivating factor when choosing technologies.

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!

Type safety is emphasized here and Python type safety has a lot of work that needs to be done to its

Not a language I associate with type safety...

Encore founder here. Thanks for the feedback, great to hear you're happy with Encore.

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)

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.

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'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).

Ever tried Pulumi? I myself am allergic to TypeScript, but seems they support using it, among a ton of other languages: https://www.pulumi.com/docs/iac/languages-sdks/javascript/

There already exists many implementations of this idea. CDK, Pulumi and Winglang are the ones that come to mind as probably the most well known.

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.

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

Founder here. Sorry to hear you're not happy with the support, appreciate the transparent feedback. We do our best to be responsive for community support requests, but sometimes we can't keep up with the volume. FWIW we offer paid private support if you feel you really need super fast response.

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.