There is no single correct way to host a Rails application in 2026. We deploy client projects across AWS Fargate, Kamal on bare metal, and dedicated servers from providers like Akamai (Linode). Each approach has genuine strengths. The right choice depends on your team, your budget, and what your application actually needs — not on what the latest conference talk recommended. This post breaks down how we make that decision.
The Rails Hosting Landscape in 2026
Rails hosting has changed significantly in the last few years. Heroku’s pricing changes pushed many teams to re-evaluate their infrastructure. Kamal arrived as a first-party deployment tool from the Rails ecosystem. AWS Fargate matured into a genuinely viable option for containerised Rails apps. And dedicated servers from providers like Akamai and Hetzner became surprisingly capable for the price.
The result is that teams now have real choices, but those choices come with trade-offs that aren’t always obvious from the documentation.
We’ve deployed Rails applications across all three approaches. Here’s what we’ve learned.
AWS Fargate: Managed Containers, Managed Complexity
Fargate runs your Docker containers without requiring you to manage the underlying EC2 instances. You define your task, set your resource limits, and AWS handles the rest. For Rails applications, this typically means an ECS cluster with Fargate tasks, an ALB for load balancing, and RDS for your database.
Where Fargate works well:
- Auto-scaling is a genuine requirement. If your application has unpredictable traffic spikes — a SaaS product that gets featured on Hacker News, or an internal tool with heavy usage during end-of-month processing — Fargate scales containers up and down without manual intervention.
- Your team is already in the AWS ecosystem. If you’re using RDS, S3, SQS, and CloudWatch, adding Fargate is a natural extension. The IAM integration, VPC networking, and logging all fit together.
- Compliance mandates managed infrastructure. Some clients need audit trails, SOC 2 alignment, or the ability to demonstrate that infrastructure is managed by a certified provider. AWS provides this out of the box.
Where Fargate gets expensive or complicated:
- NAT Gateway costs are a trap. If your Fargate tasks sit in private subnets (and they should for security), outbound internet traffic routes through a NAT Gateway. At roughly $0.045 per GB plus an hourly charge, this adds up quickly for applications that make frequent external API calls. We’ve seen NAT costs exceed the compute costs for some workloads.
- Configuration complexity is real. A production Fargate setup requires an ECS cluster, task definitions, service definitions, an ALB with target groups, security groups, VPC configuration, ECR for your images, and IAM roles tying it all together. That’s a lot of moving parts before your Rails app serves its first request.
- Cold starts affect responsiveness. Fargate tasks take time to spin up. For applications that scale to zero or scale up from a small number of tasks, users may notice latency during scaling events.
There are ways to mitigate the NAT cost problem — VPC endpoints for AWS services, NAT instances instead of managed NAT Gateways, or placing tasks in public subnets with careful security group configuration. Each approach trades cost for complexity or security considerations. We choose based on the specific project’s requirements.
Kamal: Simplicity on Your Own Metal
Kamal, created by 37signals (the team behind Rails itself), deploys Docker containers directly to servers you control. No container orchestration platform. No cloud-specific abstractions. You point Kamal at a server, and it handles building your image, pushing it, running zero-downtime deployments, and managing SSL via Let’s Encrypt.
Where Kamal works well:
- Predictable workloads on a known budget. A Rails application serving steady traffic doesn’t need auto-scaling. A $40/month dedicated server from Akamai or Hetzner can comfortably handle thousands of requests per minute for a typical Rails app with Solid Queue processing background jobs.
- Small teams that want to understand their infrastructure. Kamal’s configuration is a single YAML file. The deployment process is transparent — you can SSH into the server and see exactly what’s running. There’s no abstraction layer hiding problems from you.
- Fast iteration cycles. Deploying with Kamal is fast. Push to your registry, pull on the server, swap the container. No waiting for ECS to drain connections and stabilise a new task definition revision.
Where Kamal requires more thought:
- You manage the servers. OS updates, security patches, disk space monitoring, firewall rules — these are your responsibility. Kamal deploys your application; it doesn’t manage the host.
- Scaling means adding servers manually. Kamal can deploy to multiple servers behind a load balancer, but you provision and configure those servers yourself. There’s no auto-scaling.
- Secrets management needs a deliberate approach. We use direnv combined with 1Password CLI (
op) to inject secrets at deploy time, keeping credentials out of files and environment variables on developer machines. This works well but requires setup and team discipline.
For many of our client projects, Kamal hits the right balance. The application is containerised (so it’s portable), the deployment is simple to reason about, and the monthly cost is predictable.
Dedicated Servers: Raw Performance, Full Control
Sometimes the right answer is a dedicated machine. Not a VPS, not a container platform — an actual server (or a high-spec VPS) where your Rails application is the primary tenant.
Where dedicated servers work well:
- Performance-sensitive applications. A dedicated server from Akamai or Hetzner gives you consistent CPU and memory without noisy-neighbour effects. For applications doing heavy computation, large file processing, or serving high-throughput APIs, the performance difference is measurable.
- Cost efficiency at scale. A dedicated server with 32GB of RAM and 8 cores costs a fraction of the equivalent Fargate configuration running 24/7. If your workload is steady, you’re paying for capacity you actually use.
- Geographic requirements. Some clients need their application hosted in a specific country or region. Dedicated server providers often have broader geographic options than the major cloud platforms.
Where dedicated servers add burden:
- Everything is your responsibility. Not just the OS and security patches, but also redundancy, backups, failover, and monitoring. If the server goes down at 2am, that’s your problem.
- Scaling is a procurement exercise. Need more capacity? Order a new server, wait for provisioning, configure it, and add it to your load balancer. This takes hours or days, not minutes.
- No managed services. You’re running your own PostgreSQL, your own Redis, your own background job infrastructure. Managed equivalents (RDS, ElastiCache) handle failover and backups automatically. On a dedicated server, you build that yourself.
We typically recommend dedicated servers for applications with predictable, steady workloads where the team has the operational experience to manage the infrastructure — or where we are providing ongoing support.
Decision Framework
Rather than prescribing a single answer, here is how the three approaches compare across the factors that matter most:
Monthly budget. Fargate runs higher ($200-2,000+ depending on workload). Kamal and dedicated servers are significantly cheaper ($20-300/month) for steady traffic.
Team ops experience. Fargate needs AWS familiarity. Kamal needs basic server administration. Dedicated servers need strong ops capability across the full stack.
Scaling needs. Fargate auto-scales. Kamal scales by adding servers manually (predictable, but not instant). Dedicated servers scale by procurement — hours or days, not minutes.
Compliance requirements. Fargate provides AWS audit trails and SOC 2 alignment out of the box. With Kamal or dedicated servers, you build the compliance evidence yourself.
Deployment complexity. Fargate has high initial setup (ECS, ALB, IAM, VPC). Kamal is a single YAML file. Dedicated servers depend on your own tooling.
Ongoing maintenance. Fargate is low (AWS manages infrastructure). Kamal is medium (you manage the servers). Dedicated is high (you manage everything).
The most important question is usually the simplest: does your application need to scale dynamically? If yes, Fargate. If no, Kamal or a dedicated server will serve you well at a fraction of the cost.
The second question is about your team: who handles infrastructure when something breaks at midnight? If the answer is “we’d rather that be AWS’s problem,” Fargate is worth the premium. If your team is comfortable with server administration, the other options give you more control for less money.
Need help working through this decision? As part of our development services, we review infrastructure requirements and recommend an approach that fits your project.
The Docker Constant
One principle we apply across all three approaches: containerise everything with Docker from day one. Whether you’re deploying to Fargate, Kamal, or a dedicated server, your application runs in a Docker container built from the same Dockerfile.
This means the hosting decision is reversible. A client who starts on Kamal and later needs auto-scaling can move to Fargate without changing a line of application code. The deployment configuration changes; the application doesn’t. We’ve migrated client projects between all three approaches, and containerisation is what makes that feasible.
Ready to Choose?
If you are evaluating hosting for a Rails project and want a second opinion grounded in operational experience, get in touch. We will review your requirements and recommend the approach that fits — no lock-in, no upsell.
Frequently Asked Questions
What is Kamal and how does it compare to Fargate? Kamal deploys Docker containers straight to your own servers with zero-downtime rollouts and built-in SSL — no orchestration platform required.
When should I use AWS Fargate? When you need auto-scaling, are already in the AWS ecosystem, or must meet compliance requirements that mandate managed infrastructure.
Can I switch between hosting approaches later? Yes. If your app is containerised, moving between Fargate, Kamal, and dedicated servers is a deployment config change, not a rewrite.