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)
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.
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.
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.
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.
Yea really surprised encore isnāt more known and popular. Between it and convex they are the best things right now in building backends.
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.
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.
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.