If there is a primitive not currently supported (say running a temporal workflow service) is it possible to define a new primitive for this? Just wondering what it looks like if/when you need something not currently supported.
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.
Happy Encore customer here! I’m kind of surprised they haven’t gotten more attention. It’s like the DX of Vercel for backend and infra, but open source and you can connect it to your existing cloud provider (we use GCP, but also works with AWS). We rarely have to think about about infra or CI/CD things. It just works, and on the rare occasion it doesn’t the team has been super quick to resolve it.
It’s like having a in-house 24/7 dev ops infra team but for a fraction of the cost!
Disclaimer: Our infrastructure needs are not super complex: Web services, SQL, key-value store, pub-sub and few other parts, your mileage may vary depending on your needs.
1. I want to deploy to a testing environment where I may want to use different users, different sized services, or even mock services so I don't have to pay for them?
2. I want to develop in an isolated environment (maybe without internet or simply I'm trying to develop a narrow feature that doesn't require the rest of the infrastructure)?
3. How does it handle security elements like VPCs, IAM roles, all these things that are the context my application runs in that I don't necessarily want to couple to my application code?
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)
Part of the selling point of terraform is that I can easily switch clouds if I need to. That's only partially true, most of your terraform would need to change to move from e.g. AWS to GCP, but still, your (hard-fought) experience with terraform on one platform will help when moving to another. If I define my infra the encore way, will I be locked in to one cloud, or can I easily migrate if I need to? Furthermore, I only see Go and Typescript, do you have a roadmap for supporting more languages?
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.
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.
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.
I've only really used AWS at a startup, but this sounds kinda scary based on that experience just because it's so easy to configure services in AWS to cost you lots more. How does something like Encore figure out what to use for the nitty-gritty AWS config details without exposing the user to those decisions? I can't remember any really specific examples because it's been a while since I used AWS, but a smaller example would be something like configuring logging/time to keep logs.
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.
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.
Encore user here, support sucks and the Environment Destruction feature does not work properly, I have an environment that was stuck destroying for days (did it manually later on AWS).
Please, improve the support, we would love to pay if you guys were responsive enough.
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.
This an interesting idea, but I'd be skeptical of having this much coupling between application code and infrastructure. It's like an anti-12 Factor App.
It might make sense for something like a "serverless" app where the units of the business logic are intended to map directly onto cloud provider entities.
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).
But you're inverting the dependency-injection pattern (dependency-extraction?) rather than feeding your app the things it needs to run, you're encoding the dependencies directly into the application code. Maybe it works great in practice, I haven't tried it, but it looks brittle and hard to test.
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
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.
I literally meant typescript types... i.e. define the types of the solution rather than an algorithm... it servers the same purpose as using something like terraform:
Ah, I think what you're asking for is "declarative" configuration, rather than the typical imperative code for setting up infrastructure. I think that's what you're out after, but with strong types?
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!
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.
With SST v3 you're still specifying specific resources in code though, so at implementation time you have to decide which underlying infra you want to use. E.g. will you use Lambda or Fargate, this means using different SST components.
How Encore is different is that you only declare the semantics in code, and then at deploy you decide which infra to use depending on your needs for each environment. Similarly, you can choose at deploy time if you want to colocate services or deploy as separate processes, with no refactoring needed.
If there is a primitive not currently supported (say running a temporal workflow service) is it possible to define a new primitive for this? Just wondering what it looks like if/when you need something not currently supported.
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.
Happy Encore customer here! I’m kind of surprised they haven’t gotten more attention. It’s like the DX of Vercel for backend and infra, but open source and you can connect it to your existing cloud provider (we use GCP, but also works with AWS). We rarely have to think about about infra or CI/CD things. It just works, and on the rare occasion it doesn’t the team has been super quick to resolve it.
It’s like having a in-house 24/7 dev ops infra team but for a fraction of the cost!
Disclaimer: Our infrastructure needs are not super complex: Web services, SQL, key-value store, pub-sub and few other parts, your mileage may vary depending on your needs.
Encore founder here. Thanks for the feedback, great to hear you're happy with Encore.
How does Encore handle the following scenarios?
1. I want to deploy to a testing environment where I may want to use different users, different sized services, or even mock services so I don't have to pay for them? 2. I want to develop in an isolated environment (maybe without internet or simply I'm trying to develop a narrow feature that doesn't require the rest of the infrastructure)? 3. How does it handle security elements like VPCs, IAM roles, all these things that are the context my application runs in that I don't necessarily want to couple to my application code?
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)
Part of the selling point of terraform is that I can easily switch clouds if I need to. That's only partially true, most of your terraform would need to change to move from e.g. AWS to GCP, but still, your (hard-fought) experience with terraform on one platform will help when moving to another. If I define my infra the encore way, will I be locked in to one cloud, or can I easily migrate if I need to? Furthermore, I only see Go and Typescript, do you have a roadmap for supporting more languages?
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.
Do you consider supporting rust?
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.
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.
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.
Curious about how this compares to alchemy - https://alchemy.run/
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.
I've only really used AWS at a startup, but this sounds kinda scary based on that experience just because it's so easy to configure services in AWS to cost you lots more. How does something like Encore figure out what to use for the nitty-gritty AWS config details without exposing the user to those decisions? I can't remember any really specific examples because it's been a while since I used AWS, but a smaller example would be something like configuring logging/time to keep logs.
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.
9x faster than express is a bold claim, would be interesting to see how it holds up with real application logic and some real benchmarks/usecases.
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.
Encore user here, support sucks and the Environment Destruction feature does not work properly, I have an environment that was stuck destroying for days (did it manually later on AWS).
Please, improve the support, we would love to pay if you guys were responsive enough.
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.
Yea really surprised encore isn’t more known and popular. Between it and convex they are the best things right now in building backends.
This an interesting idea, but I'd be skeptical of having this much coupling between application code and infrastructure. It's like an anti-12 Factor App.
It might make sense for something like a "serverless" app where the units of the business logic are intended to map directly onto cloud provider entities.
It reminds me of https://aws.github.io/chalice/ but cloud-agnostic and Typescript in place of Python
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).
But you're inverting the dependency-injection pattern (dependency-extraction?) rather than feeding your app the things it needs to run, you're encoding the dependencies directly into the application code. Maybe it works great in practice, I haven't tried it, but it looks brittle and hard to test.
What's the pricing model? Couldn't figure that out neither on Github nor on your webpage.
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
Have been watching Encore for a while, excited about prospects of it in other languages like Python!
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...
Pretty interesting. I wish this was available for .net. Would love to try this out.
As Ops guy, all infrastructure declared in application code eventually leads to crying if you get big enough.
That being said, I know we are expensive and "don't add to bottom line" so this looks like good enough hacky kludge as anything else.
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.
cool...
btw, on a tangent, I always thought that infra can be defined in typescript types.... is is strange but no need for custom language
someone please steal this idea and make something out of it
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/
I literally meant typescript types... i.e. define the types of the solution rather than an algorithm... it servers the same purpose as using something like terraform:
``` interface BaseEC2 extends AWSEC2 { type: '...' }
// export means build export interface MyInstance extends BaseEC2 { // some customisations }
// fleet export interface EC2Fleet extends EC2Fleet { instances: MyInstance } ```
etc...
wacky idea but I kind of like it
Ah, I think what you're asking for is "declarative" configuration, rather than the typical imperative code for setting up infrastructure. I think that's what you're out after, but with strong types?
Exactly...
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.
the type-safe infrastructure primitives are interesting, curious how it compares to something like effect or nestjs for actual production use
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!
Is Azure support on the roadmap?
How does it compare with SST?
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.
SST has not been AWS-specific since Aug 2024 [1], it is now based on Pulumi/Terraform instead of CDK/CloudFormation.
[1] https://sst.dev/blog/sst-v3
With SST v3 you're still specifying specific resources in code though, so at implementation time you have to decide which underlying infra you want to use. E.g. will you use Lambda or Fargate, this means using different SST components. How Encore is different is that you only declare the semantics in code, and then at deploy you decide which infra to use depending on your needs for each environment. Similarly, you can choose at deploy time if you want to colocate services or deploy as separate processes, with no refactoring needed.
Ah, been a while since I looked into it. Thanks for the correction!
Opened it, saw I needed to wrap my routes with api(), closed it - sounds like a solution for a problem PaaS has solved 10 years ago.