Encore vs Nitric vs Ampt: Cloud-Native Backend Frameworks 2026

The modern backend developer spends roughly 40% of their time on infrastructure configuration. Terraform files, CloudFormation templates, IAM policies, VPC networking, service mesh configuration. None of that code ships product value. It exists purely to satisfy the deployment pipeline, and it rots faster than application code because cloud providers release breaking changes quarterly.

Three frameworks have emerged with genuinely different answers to this problem: Encore, Nitric, and Ampt. Each one eliminates infrastructure boilerplate, but they disagree on almost everything else: which languages you should write, how tightly coupled your code should be to a specific cloud, and whether "infrastructure from code" is a better abstraction than "infrastructure as code."

We have deployed production workloads with all three across client projects at Kanopy. The right choice depends on your team's language preferences, your cloud provider commitments, and how much control you are willing to trade for speed. This comparison covers the specific tradeoffs that matter for teams making this decision today.

Encore takes the most opinionated stance of the three. It introduces a custom compiler that analyzes your Go or TypeScript source code, extracts infrastructure requirements from annotations and type signatures, and generates the cloud resources automatically. You do not write Terraform. You do not configure AWS services. You write application code with Encore-specific decorators, and the framework figures out what infrastructure you need.

The local development story is where Encore genuinely separates itself. Running encore run spins up a local environment that includes a real PostgreSQL database, a Pub/Sub emulator, caching, and cron scheduling. No Docker Compose files. No local Kubernetes cluster. The Encore daemon manages everything and provides a built-in dashboard showing request traces, database queries, and architecture diagrams that update as you write code.

Encore's infrastructure graph is the key technical innovation. The compiler builds a directed acyclic graph of every service, database, topic, and API call in your application. It uses this graph to generate optimized infrastructure for each cloud provider. On AWS, a Pub/Sub topic becomes SNS + SQS. On GCP, it becomes Google Cloud Pub/Sub. Your code stays identical. The Encore Platform (their hosted CI/CD and infrastructure management layer) handles provisioning, and you can eject to raw Terraform if you outgrow the platform.

The pricing model is straightforward: free for individual developers and small teams (up to 2 cloud environments), with paid plans starting at $99/month per team member for production features like preview environments, secrets management, and custom domains. Self-hosting Encore's open-source runtime is free, but you lose the managed infrastructure provisioning.

Nitric approaches the problem from the opposite direction. Instead of a custom compiler that reads your code structure, Nitric provides a runtime SDK that wraps cloud services behind a consistent API. You call nitric.api("main") to declare an API, nitric.bucket("uploads") for object storage, or nitric.topic("orders") for messaging. At deploy time, Nitric's "providers" translate these declarations into cloud-specific resources.

The language support is the broadest of all three frameworks. Nitric ships official SDKs for TypeScript, Python, Go, C#, and Dart. Each SDK provides the same interface, so a Python team and a Go team within the same organization can share architectural patterns without sharing a runtime. This matters for larger engineering organizations where language standardization is a political nonstarter.

Nitric's cloud provider story is its strongest selling point. Out of the box, it deploys to AWS, Google Cloud, and Azure with full parity across all three. The abstraction is not superficial. A Nitric bucket on AWS provisions S3 with proper IAM policies, event notifications, and lifecycle rules. The same declaration on Azure provisions Blob Storage with equivalent configuration. Switching providers means changing a single deployment configuration value, not rewriting application code.

Local development uses Docker containers to emulate cloud services. Running nitric start launches a local gateway, storage emulator, and topic emulator. It is heavier than Encore's built-in daemon but more flexible because you can attach debuggers and run integration tests against the same container environment that mirrors production. Nitric also provides a local dashboard, though it is not as polished as Encore's architecture visualization.

The framework is fully open source under the Apache 2.0 license. There is no paid tier for the core framework. Nitric's business model centers on enterprise support contracts and a forthcoming managed deployment platform. For teams that want complete control over their deployment pipeline, this model is attractive because there is no vendor lock-in at the framework level.

Ampt occupies a different niche entirely. It is purpose-built for Node.js and TypeScript developers who want the fastest possible path from code to running cloud infrastructure. Where Encore and Nitric abstract across multiple languages and clouds, Ampt focuses on doing one thing exceptionally well: making AWS deployment feel as fast as local development.

The developer experience is genuinely impressive. Running ampt in your terminal creates a personal developer sandbox on AWS. Every file save syncs to your sandbox in under a second. You are not working against a local emulator. You are working against real AWS services (DynamoDB, S3, SQS, API Gateway) in a sandboxed environment that costs fractions of a penny per hour. This eliminates an entire class of "works locally but breaks in production" bugs because there is no local environment to diverge from.

Ampt provides its own data layer called Ampt Storage, a key-value and document store built on DynamoDB that abstracts away capacity planning, partition key design, and GSI management. For teams that do not want to become DynamoDB experts, this is significant. You write data.set("user:123", userData) and Ampt handles indexing, querying, and scaling. For teams that need relational data, Ampt supports connecting to external databases, but the native storage layer is where the framework shines.

Task scheduling, event handling, and HTTP routing all use simple decorators. @ampt/api gives you Express-compatible routing. @ampt/tasks handles background jobs. @ampt/events manages pub/sub messaging. The API surface is small enough that a mid-level developer can learn the entire framework in an afternoon, which is not true of Encore or Nitric.

Pricing follows a consumption model. The free tier includes 10,000 requests per day and 1 GB of storage. The Pro plan at $20/month per developer sandbox adds custom domains, increased limits, and team features. Production environments are priced based on AWS resource consumption with a small Ampt platform fee. For small teams building API-driven products, the total cost is typically under $50/month until you hit meaningful scale.

Developer experience is where these frameworks win or lose adoption, and each one optimizes for a different kind of developer.

Encore delivers the best experience for Go developers. The custom compiler catches infrastructure misconfigurations at compile time, before you deploy. Type-safe API calls between services, automatic API documentation, and the architecture diagram that updates live as you code are features no other framework matches. The TypeScript support is solid but clearly secondary. If your team writes Go, Encore is the most productive backend framework available today.

The tradeoff is rigidity. Encore requires you to structure your project according to its conventions. Each service lives in its own directory. Database migrations follow Encore's format. You cannot bring your own ORM or database driver for Encore-managed databases. Teams that have strong opinions about project structure will find this constraining.

Nitric wins on flexibility. Five languages, three clouds, and minimal opinions about project structure mean you can adopt Nitric incrementally. Add the SDK to an existing Express app, wrap your routes in Nitric's API declaration, and deploy. The learning curve is gentle because the SDK is a thin layer, not a framework that takes over your application lifecycle.

The downside is that Nitric gives you less "for free." You manage your own database connections, write your own authentication middleware, and handle your own API documentation. Nitric abstracts cloud resources, not application patterns. For experienced teams this is ideal. For teams that want batteries included, it requires more upfront work.

Ampt provides the lowest friction onboarding of the three. The sub-second sync to a real AWS environment means you can start building without understanding any cloud concepts. The built-in data layer, task scheduler, and event system cover 80% of backend requirements without external dependencies. If your team is JavaScript-native and builds primarily on AWS, Ampt removes the most friction.

The limitation is scope. Ampt only supports Node.js and TypeScript. It only deploys to AWS. If you need Python microservices, Go workers, or multi-cloud deployment, Ampt cannot help. It is a specialist tool for a specific developer profile.

The level of abstraction each framework provides determines how much cloud-specific knowledge your team needs and how locked in you become.

Encore uses "infrastructure from code," which means the framework reads your source code and decides what infrastructure to create. You never see Terraform or CloudFormation unless you choose to eject. The upside is zero infrastructure configuration. The downside is you cannot customize infrastructure details without ejecting from the managed platform. Need a specific S3 bucket policy? A custom VPC CIDR range? You either wait for Encore to support it or eject to self-managed Terraform.

Encore supports AWS and GCP today with Azure on the roadmap. Switching between AWS and GCP requires no code changes for most workloads, though edge cases around database features can differ between providers.

Nitric uses "provider plugins" that translate framework declarations into cloud-specific Terraform or Pulumi configurations. The default providers cover AWS, GCP, and Azure. You can write custom providers for any target, including on-premises Kubernetes clusters. If you need to run the same application on AWS for US customers and on Azure for EU customers (common in regulated industries), Nitric is the only framework of the three that supports this cleanly.

The migration path from Nitric is also the least painful. Since the SDK is a library you import, not a compiler that processes your code, removing Nitric means replacing SDK calls with direct cloud SDK calls. A team can migrate a service away from Nitric in a few days. Migrating away from Encore requires restructuring your entire project because the compiler annotations are woven into your code structure.

Ampt ties you to AWS, and it does so intentionally. The instant sync, the managed data layer, and the sandbox model all depend on AWS-specific services. There is no multi-cloud story and no plans for one. If your organization has committed to AWS (and most startups have, given AWS's market share), this is not a problem. If you have a contractual obligation to support multiple clouds, Ampt is off the table.

For teams evaluating whether Kubernetes or serverless fits their workload, these frameworks represent a third path: serverless deployment with framework-managed infrastructure that feels like traditional backend development.

Testing strategy differs significantly across the three frameworks, and this impacts your team's ability to catch bugs before they reach production.

Encore provides built-in testing utilities that spin up isolated test environments with real databases and service mocks. In Go, you run encore test ./... and each test gets its own database that is created and destroyed automatically. The test runner is aware of service boundaries, so integration tests that span multiple services work without manual service orchestration. This is the most sophisticated testing story of the three frameworks.

Encore also includes built-in distributed tracing. Every request is traced across service boundaries with automatic span creation. The Encore Platform dashboard shows traces, logs, and metrics in a single view. You do not need to configure OpenTelemetry, Jaeger, or Datadog. For teams without a dedicated platform engineering function, this saves weeks of observability setup.

Nitric relies on standard testing tools for each language. You write unit tests with pytest, Jest, or Go's testing package and use Nitric's local emulator for integration tests. The framework does not provide custom testing utilities, but it also does not interfere with your existing testing setup. Observability is bring-your-own: you add OpenTelemetry, connect your preferred monitoring tool, and instrument your code. This requires more work but gives you complete control over your observability stack.

Ampt's testing story leverages the sandbox model. Since every developer gets their own cloud environment, integration testing happens against real AWS services by default. Ampt provides @ampt/test for running automated tests in the sandbox, and the sub-second deployment cycle means test-driven development feels nearly instantaneous. The built-in ampt logs command streams CloudWatch logs to your terminal, and Ampt's dashboard shows basic request metrics.

For production readiness, all three frameworks handle the basics: environment variables, secrets management, and CI/CD integration. Encore's managed platform is the most production-ready out of the box because it handles provisioning, scaling, and monitoring automatically. Nitric requires you to set up your own deployment pipeline (typically GitHub Actions or GitLab CI calling nitric up). Ampt provides a built-in CI/CD pipeline that deploys on git push, similar to Vercel's model for frontend applications.

Raw performance benchmarks between frameworks are misleading because each framework generates different underlying infrastructure. But the scaling characteristics matter for capacity planning and cost estimation.

Encore on AWS deploys services as Fargate tasks behind an Application Load Balancer. On GCP, it uses Cloud Run. Both are container-based, which means cold starts are measured in low hundreds of milliseconds and warm request latency is determined by your application code, not the framework. Encore's compiled Go services typically handle 5,000+ requests per second per container with sub-10ms p99 latency for simple CRUD operations. The TypeScript runtime is roughly 3x slower for compute-heavy workloads but equivalent for I/O-bound API services.

Nitric deploys to whatever compute target the provider plugin specifies. The default AWS provider uses Lambda for API handlers, which means you get Lambda's scaling characteristics: near-instant scaling to thousands of concurrent executions, but cold starts of 200-500ms for Node.js and 500-1000ms for Go (due to the Nitric runtime initialization overhead). You can write custom providers that deploy to ECS, Cloud Run, or Kubernetes if cold starts are unacceptable for your use case.

Ampt deploys to Lambda behind API Gateway with an optimized packaging pipeline that keeps deployment artifacts small. Cold starts are typically under 300ms for a standard Express application. Warm latency is 5-15ms for API routes that hit the built-in data layer. The data layer adds approximately 2-5ms of overhead compared to raw DynamoDB calls due to the abstraction handling indexing and query translation.

For teams focused on reducing cloud spend, the cost profiles differ significantly. Encore's Fargate-based deployment means you pay for compute even during idle periods (minimum ~$30/month for a single service). Nitric and Ampt's Lambda-based deployments scale to zero, making them cheaper for low-traffic applications but potentially more expensive at high throughput due to per-request pricing. The crossover point is typically around 10 million requests per month, at which point container-based deployment becomes more cost-effective.

Adopting a new backend framework is a multi-month commitment. The migration path matters as much as the feature set.

Starting with Encore: The highest-value migration path is new services. If your team is building a new microservice, write it in Encore while keeping existing services unchanged. Encore services expose standard HTTP APIs, so your existing infrastructure can call them without modification. Migrating an existing service to Encore requires restructuring the project to match Encore's directory conventions, adding compiler annotations to every endpoint, and replacing your database layer with Encore's managed migrations. Budget 2-3 weeks per service for a small team.

Starting with Nitric: The lowest-friction adoption path. Add the Nitric SDK as a dependency, wrap your existing route handlers in Nitric declarations, and deploy. An Express application can be "Nitric-ified" in a day because the SDK wraps your existing code rather than replacing it. The gradual migration path is to replace direct AWS SDK calls with Nitric SDK calls one resource at a time (start with object storage, then add messaging, then move API definitions). Full migration of a mid-size service takes 1-2 weeks.

Starting with Ampt: Best for greenfield projects. Migrating an existing Express application to Ampt is straightforward if you are already on AWS: install the Ampt CLI, wrap your Express app with Ampt's HTTP handler, and deploy. Migrating your data layer to Ampt Storage is optional but recommended for new features. The main friction point is moving away from DynamoDB-specific query patterns or PostgreSQL to Ampt's document store, which requires rethinking data access patterns.

For all three frameworks, the recommendation is the same: start with a non-critical service, run it in production for 30 days, and evaluate developer satisfaction and operational overhead before committing to a broader migration.

After deploying production workloads with all three frameworks, here is the decision matrix we use with clients.

Choose Encore if: Your team writes Go (or is willing to). You want batteries-included observability and testing. You are comfortable with an opinionated project structure. You deploy to AWS or GCP. You value compile-time safety and architecture visualization. Your team size is under 20 engineers.

Choose Nitric if: You need multi-cloud deployment. Your engineering organization uses multiple programming languages. You want the flexibility to customize your deployment target (Lambda, containers, Kubernetes). You prefer open-source tools without vendor lock-in. You have platform engineers who can manage the deployment pipeline.

Choose Ampt if: Your team is JavaScript/TypeScript-native. You are committed to AWS. You want the fastest possible development cycle for API-driven products. You value simplicity over configurability. You are building a startup product where shipping speed matters more than infrastructure flexibility.

Pick the one that matches your team's language, cloud, and complexity preferences. Deploy a real service. Iterate from there.

If your team is evaluating backend frameworks and wants an expert assessment of which option fits your architecture, book a free strategy call with our engineering team. We have hands-on experience with all three and can help you avoid the migration pitfalls we have seen across dozens of client projects.