Show HN: Encore – Type-safe back end framework that generates infra from code
26 points
2 hours ago
| 10 comments
| github.com
| HN
sausagefeet
54 minutes ago
[-]
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?

reply
andout_
22 minutes ago
[-]
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)
reply
danielstocks
58 minutes ago
[-]
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.

reply
machekb
18 minutes ago
[-]
Encore founder here. Thanks for the feedback, great to hear you're happy with Encore.
reply
_pdp_
8 minutes ago
[-]
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

reply
embedding-shape
4 minutes ago
[-]
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/
reply
nevon
3 minutes ago
[-]
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.
reply
wolando
1 hour ago
[-]
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?
reply
andout_
1 hour ago
[-]
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.

reply
phpnode
44 minutes ago
[-]
Curious about how this compares to alchemy - https://alchemy.run/
reply
andout_
15 minutes ago
[-]
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.
reply
rubenvanwyk
1 hour ago
[-]
Have been watching Encore for a while, excited about prospects of it in other languages like Python!
reply
ninetyninenine
18 minutes ago
[-]
Type safety is emphasized here and Python type safety has a lot of work that needs to be done to its
reply
thecupisblue
1 hour ago
[-]
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.
reply
andout_
1 hour ago
[-]
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.
reply
fulafel
36 minutes ago
[-]
How does it compare with SST?
reply
andout_
9 minutes ago
[-]
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.
reply
ForHackernews
20 minutes ago
[-]
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

reply
andout_
1 minute ago
[-]
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).

reply
stmblast
1 hour ago
[-]
the type-safe infrastructure primitives are interesting, curious how it compares to something like effect or nestjs for actual production use
reply
andout_
1 hour ago
[-]
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!
reply