
Last updated: July 19, 2026. Every price, region count, and plan name below was re-checked against Railway, Render, and Fly.io's live pricing and documentation pages on this date. Render restructured its team pricing in April 2026 and Railway shipped experimental HA Postgres in March 2026, both of which are reflected here.
The Railway vs Render vs Fly.io decision boils down to three different philosophies: Railway gives you usage-based simplicity, Render gives you managed production infrastructure, and Fly.io gives you global edge deployment with full Docker control. Since Heroku announced its shift to sustaining engineering in early 2026 -- no new features, no new enterprise contracts, thousands of developers need a new home. This post compares all three with real dollar amounts at four traffic tiers, side-by-side deploy configs, and a stage-of-company framework so you can stop reading comparisons and start shipping. (If you're deploying a static site or frontend-only app instead of a backend service, our Vercel vs Netlify comparison is the more relevant read.)
Railway vs Render vs Fly.io at a Glance
Here's the 30-second version before we dig into each category.
| Feature | Railway | Render | Fly.io |
|---|---|---|---|
| Best For | Prototypes, side projects | Production SaaS | Global, latency-sensitive apps |
| Pricing Model | Usage-based (per-second) | Flat-rate tiers | Usage-based, no free allowance for new orgs |
| Free Tier | No (removed 2023, $5 trial credit) | Yes (limited, 15min spin-down) | No for new orgs (short trial, card required) |
| Regions | 4 | 5 (Oregon, Ohio, Virginia, Frankfurt, Singapore) | 18 |
| Managed Postgres | Containerized; experimental HA add-on since Mar 2026 | Full managed (PITR, replicas) | Community-maintained (unmanaged) |
| Autoscaling | Automatic, zero-config | Threshold-based (CPU/memory) | Proxy autostop + metrics-based |
| Build System | Railpack / Nixpacks | Native buildpacks | Dockerfile required |
| CLI | railway up | No native CLI (dashboard) | fly deploy |
| Docker Required | No | No | Effectively yes |
| Scale-to-Zero | No (stays warm on paid) | Free tier only (cold starts) | Yes (Machines wake on request) |
| PR Preview Environments | Yes (auto-deleted on merge) | Yes (full infra copies) | Manual setup |
| Team RBAC | Pro plan and up | Pro workspace, $25/mo flat | Organizations |
The high-level takeaway: Railway is the fastest path from code to URL. Render is where you graduate when you need production-grade Postgres and predictable bills. Fly.io is where you go when your users span continents and you're comfortable with Docker. Let's break each category down.
How Does Pricing Actually Work?
Pricing is the number-one factor in every deployment platform thread on Reddit and Hacker News, and the three platforms couldn't be more different in how they charge you.
Railway: Pay-Per-Second Simplicity
Railway bills by the second for CPU and memory. The rate is $0.00000772/vCPU-second for compute and $0.00000386/GB-second for memory. Egress runs $0.05/GB. You pay for exactly what your app consumes, nothing more. The Hobby plan costs $5/month as a subscription (which acts as a spending cap), while the Pro plan is $20/month per seat with no resource caps.
The catch? There's no free tier anymore. Railway removed it in 2023 and replaced it with a one-time $5 trial credit.
Render: Flat-Rate Predictability
Render uses fixed monthly pricing per service. A Starter web service is $7/month, Standard is $25/month, and Pro tiers scale from $85/month up to $450/month at Pro Ultra (32GB RAM, 8 CPU). Managed Postgres now runs on Render's "flexible plans," compute starts around $6/month on the Basic tier, but storage is billed separately at $0.30/GB/month rather than bundled into the flat rate the way it used to be. Egress is included in most plans, with 5GB included on the free workspace plan.
The free tier exists but comes with a real trade-off: services spin down after 15 minutes of inactivity, and the first request after that takes about a minute to respond. For hobby projects that get sporadic traffic, this can be painful. Render also restructured its workspace/team plans on April 23, 2026 (more on that in the Team Features section below), so if you've been pricing Render off an older comparison, check that section before you budget.
Fly.io: Usage-Based With a Learning Curve
Fly.io charges per VM-second with a Machines billing model. A shared-cpu-1x with 256MB RAM runs roughly $2.02/month if running 24/7. Volumes cost $0.15/GB/month. Egress splits into three regional tiers: $0.02/GB in North America and Europe, $0.04/GB in Asia Pacific, Oceania, and South America, and $0.12/GB in Africa and India.
There is no ongoing free allowance for new accounts anymore. Fly.io deprecated the Hobby/Launch/Scale plans that included a $5/month free credit for any organization created after October 7, 2024. New signups get a short free trial (2 VM hours or 7 days, whichever ends first) and then must add a valid credit card and pay from the first dollar of usage. Only accounts that predate that cutoff keep the old free allowance.
The common developer complaint? Fly.io pricing "requires a spreadsheet" to predict. The per-component billing (Machines + Volumes + egress + IPs) adds up in ways that aren't obvious until you get your first invoice, and now there's no free credit to soften that first bill.
Real Monthly Costs: Same App, Three Platforms
Here's what the same stack actually costs on each platform. These are estimates based on published rates, your mileage will vary with traffic patterns and resource consumption.
| Tier | Stack | Railway | Render | Fly.io |
|---|---|---|---|---|
| Hobby | 1 web + 1 DB, <100 req/day | ~$5/mo | $0 (free tier) | ~$4-6/mo |
| Startup | 1 web + 1 worker + Postgres + Redis, ~500 req/min | ~$25-40/mo | ~$50-60/mo | ~$20-35/mo |
| Growth | 2 web + 1 worker + Postgres + Redis, ~2K req/min | ~$80-120/mo | ~$130-175/mo | ~$60-90/mo |
| Scale | 4 web + 2 workers + Postgres cluster + Redis, 10K+ req/min | ~$250-400/mo | ~$350-500/mo | ~$150-250/mo |
A few things jump out. Railway and Fly.io are cheaper at almost every tier because you only pay for actual consumption. Render's flat-rate model means you're paying for reserved capacity whether you use it or not, but you'll never get a surprise bill at 3 AM either. Note the Fly.io Hobby estimate moved up from earlier versions of this comparison: with the free allowance gone for new accounts, that ~$4-6/mo (one small web Machine plus one small Postgres Machine) comes out of your card on day one, not out of a credit.
"Estimated Monthly Cost by Tier"
Data table
| "Tier" | "Railway" | "Render" | "Fly.io" |
|---|---|---|---|
| "Hobby" | 5 | 0 | 5 |
| "Startup" | 32 | 55 | 27 |
| "Growth" | 100 | 152 | 75 |
| "Scale" | 325 | 425 | 200 |
At scale, Fly.io's $0.02/GB egress in North America and Europe gives it a meaningful edge over Railway's flat $0.05/GB. If most of your traffic is in Asia Pacific, Fly.io's egress rate doubles to $0.04/GB and the gap narrows, still cheaper than Railway, just less dramatically. If your app serves a lot of static assets or API responses, egress costs can quietly become your biggest line item.
Verdict: Fly.io wins on raw cost at scale. Railway wins for pay-what-you-use simplicity. Render wins for predictable billing, you'll always know exactly what next month costs.
Developer Experience and Deployment Workflow
DX is the second-biggest factor, and it's where these platforms feel most different day-to-day.
First Deploy: Git Push vs CLI vs Docker
Railway is genuinely the fastest path from repo to running app. Connect your GitHub repo, push, and Railway auto-detects your runtime with Railpack (the successor to Nixpacks, which is now in maintenance mode). No Dockerfile, no config file, no build commands. Alternatively, railway up from your terminal deploys in seconds.
Render is similarly straightforward. Connect GitHub, pick your branch, and Render's native buildpacks handle the rest. There's no native CLI, everything goes through the dashboard or the API. For developers who prefer a GUI workflow, this is fine. For CLI-first developers, it's a gap.
Fly.io requires flyctl and, in practice, a Dockerfile. Community buildpacks exist, but most Fly.io users end up writing their own Dockerfile for control. The learning curve is steeper, but the payoff is that you understand exactly what's running in your container. If maintaining a Dockerfile isn't something your team wants to own, we've compared the lighter-weight alternatives to Dockerfiles separately.
For a deeper look at how Railpack, Nixpacks, and Dockerfiles compare as container build system choices, we covered that in a dedicated post.
| Aspect | Railway | Render | Fly.io |
|---|---|---|---|
| Time to First Deploy | ~2 minutes | ~3-5 minutes | ~5-10 minutes |
| CLI | railway up (excellent) | No native CLI | fly deploy (powerful) |
| Build System | Railpack (auto-detect) | Native buildpacks | Dockerfile |
| Dashboard | Visual canvas (unique) | Clean, standard | Minimal |
| Learning Curve | Low | Low | Medium-High |
Side-by-Side Deploy Configs
Here's the same Node.js app deployed on all three platforms. This is the practical difference you'll feel every day.
Fly.io, fly.toml:
app = "my-node-app"
primary_region = "iad"
[build]
dockerfile = "Dockerfile"
[deploy]
release_command = "npx prisma migrate deploy"
[http_service]
internal_port = 3000
force_https = true
auto_stop_machines = "stop"
auto_start_machines = true
min_machines_running = 0Render, render.yaml:
services:
- type: web
runtime: node
name: my-node-app
plan: starter
buildCommand: npm install && npm run build
startCommand: npm start
envVars:
- key: NODE_ENV
value: production
autoDeploy: trueRailway, railway.json (optional, Railpack auto-detects most settings):
{
"$schema": "https://railway.com/railway.schema.json",
"build": {
"builder": "railpack"
},
"deploy": {
"startCommand": "npm start",
"healthcheckPath": "/health",
"restartPolicyType": "ON_FAILURE"
}
}Notice how Railway's config is optional, Railpack figures out the build from your package.json. Fly.io's fly.toml gives you the most control (deployment strategy, release commands, scale-to-zero settings) but demands the most knowledge. Render's render.yaml sits in the middle: declarative infrastructure-as-code without needing Docker expertise.
Verdict: Railway wins for developer experience. Fastest to deploy, best CLI, zero mandatory config. Render is a close second for teams who prefer dashboard workflows. Fly.io trades DX for control, worth it only if you need what Docker gives you.
Databases and Managed Services
Your database choice might matter more than your compute choice. Here's where the platforms diverge sharply.
Managed Postgres: The Real Differences
Render has the strongest database story by far. Their managed Postgres includes point-in-time recovery (PITR) on all paid instances, read replicas on larger tiers, AES-256 encryption at rest, automated backups, slow query logs, and automatic storage scaling. This is production-grade infrastructure that would cost you significant DevOps time to replicate.
Railway offers containerized Postgres that's dead simple to spin up, click a button, get a connection string. The default is still a single node with no PITR and no read replicas. Railway shipped an experimental one-click HA Postgres upgrade in March 2026, a Patroni-managed cluster with etcd for leader election and HAProxy for routing, gated behind its paid Priority Boarding tier. It's worth watching, but Railway itself labels it experimental and explicitly says not to run production databases on it yet. For side projects and early-stage apps, the default containerized Postgres is perfectly fine. For production workloads handling real customer data, the absence of a production-ready PITR option is still a meaningful risk today.
Fly.io takes a different approach entirely. Fly Postgres exists but Fly.io is explicit that it's not a managed database: "If Postgres crashes because it ran out of memory or disk space, you'll need to do a little work to get it back." They can't provide support for it. Most experienced Fly.io users pair it with an external managed database like Neon, Supabase, or PlanetScale, we put the three most common Postgres-compatible picks head-to-head here if you need help choosing one.
Redis, Cron, and Everything Else
| Service | Railway | Render | Fly.io |
|---|---|---|---|
| Postgres | Containerized; experimental HA (Mar 2026, not production-ready) | Fully managed (PITR, replicas) | Community-maintained (unmanaged) |
| Redis | Native (one-click) | Native (managed) | Upstash partnership |
| Cron Jobs | Built-in | Built-in | Manual (fly-cron or external) |
| Object Storage | No | No (use S3/Cloudflare R2) | Tigris (native) |
| PITR | No on the default tier (experimental HA add-on only) | Yes (all paid plans) | No |
| Read Replicas | No on the default tier (experimental HA add-on only) | Yes (larger tiers) | Manual setup |
Verdict: Render wins for database-heavy applications. If your app's data layer is critical (and it almost always is), Render's managed Postgres is a genuine production advantage today. Railway's experimental HA Postgres narrows the gap on paper, but Railway's own changelog says not to trust it with production data yet, so treat Railway as best for fast iteration where DB features matter less until that graduates out of experimental status. Fly.io users should budget for an external managed database.
Scaling and Global Deployment
This is where Fly.io justifies its steeper learning curve.
Multi-Region: Fly.io's Edge Network
Fly.io runs your containers across 18 regions spanning North America, Europe, Asia-Pacific, South America, and Africa. Your app runs close to your users with sub-20ms latency from most populated areas. Deploy to multiple regions with a single command, this is Fly.io's core value proposition.
Render offers 5 regions (Oregon, Ohio, Virginia, Frankfurt, Singapore), Virginia joined the lineup as Render's newest US East location. Each service is pinned to one region. If your users are mostly in one geography, this is plenty. If they're global, you're adding 100-200ms of latency for users far from your chosen region.
Railway runs 4 regions on its second-generation Metal hardware (US West, US East/Virginia, EU West/Amsterdam, Southeast Asia/Singapore), and its 2026 roadmap calls for four more datacenter sites, but multi-region deployment still isn't its focus. Railway optimizes for simplicity, not geographic distribution.
Scale-to-Zero: What Actually Happens When Nobody's Using Your App
This matters a lot for hobby projects and internal tools that sit idle most of the day.
Fly.io Machines support true scale-to-zero. Set auto_stop_machines = "stop" in your fly.toml, and Fly Proxy stops your Machine when there's no traffic. The next incoming request triggers a cold start, typically 300ms-2s depending on your app's boot time. This is HTTP-based autoscaling distinct from the metrics-based autoscaler, which explicitly will not scale to zero.
Render's free tier spins down after 15 minutes of inactivity with 30-60 second cold starts. Paid plans stay warm, Render does not support scale-to-zero on paid instances (minimum instance count is always 1).
Railway doesn't offer scale-to-zero. Your services stay warm on paid plans, which means consistent performance but also consistent billing even during idle periods.
Autoscaling Under Load
| Capability | Railway | Render | Fly.io |
|---|---|---|---|
| Regions | 4 | 5 | 18 |
| Multi-Region Deploy | Limited | Single region per service | Native (one command) |
| Scale-to-Zero | No | Free tier only | Yes (Machines) |
| Autoscaling Type | Automatic | Threshold-based (CPU/memory) | Proxy + metrics-based |
| Cold Start (scale-to-zero) | N/A | 30-60s (free tier) | 300ms-2s |
| Min Instance (paid) | 1 | 1 | 0 |
Verdict: Fly.io wins for global deployment and scale-to-zero, it's not close. If your users span multiple continents or you need true scale-to-zero economics, Fly.io is the only real option here. Render wins for simple autoscaling with predictable behavior. Railway wins for zero-config scaling where you don't think about infrastructure at all.
Team Features, CI/CD, and Collaboration
This is the section no other Railway vs Render vs Fly.io comparison covers, and it matters a lot once you're past the solo developer stage.
Team Roles and Access Control
Railway supports team workspaces with role-based access on Pro plans. PR environments are a standout feature: every pull request gets a temporary environment that auto-deletes when the PR is merged or closed. They also support Focused PR Environments for monorepos. Full environment RBAC is Enterprise-only.
Render offers PR preview environments that create full infrastructure copies (including databases) for every pull request. You can control costs with previewPlan settings and auto-expire previews with expireAfterDays. This requires a Pro workspace plan, Render replaced the old per-seat Professional plan ($19/member/month) with a flat $25/month Pro plan that includes unlimited team members, effective April 23, 2026. Workspaces still on the legacy plan can opt in any time before August 1, 2026, after which they migrate automatically. For a five-person team, that's the difference between $95/month and $25/month for the same preview-environment access.
Fly.io has Organizations for team management, but preview environments require manual setup, there's no built-in PR integration. Most teams using Fly.io wire this up through GitHub Actions.
Preview Environments and CI/CD Pipelines
| Feature | Railway | Render | Fly.io |
|---|---|---|---|
| PR Preview Environments | Yes (auto-created, auto-deleted) | Yes (full infra copies with DB) | Manual (GitHub Actions) |
| Staging Environments | Yes (persistent) | Yes (Blueprint based) | Manual |
| Team Roles / RBAC | Pro plan | Pro workspace | Organizations |
| SSO | Enterprise | Scale plan and up | Not available |
| Seat Pricing | $20/seat (Pro) | $25/mo flat, unlimited seats (Pro) | Per organization |
| Audit Logs | Enterprise | Pro plan and up | Limited |
| GitHub Actions Integration | Native | API-based | Native (flyctl) |
Verdict: Render wins for teams, and it got a better deal in April 2026 when it moved off per-seat pricing. Native PR preview environments with full database copies are a killer feature for startups shipping fast, and now they come with a flat $25/month workspace fee instead of scaling per head. Railway is a close second with its auto-managed PR environments. Fly.io requires the most glue work for team workflows.
How Techsy Helps Startups Choose Their Stack
We've helped dozens of startups navigate exactly this decision, and the answer is never as simple as "just use X."
Our approach starts with four questions: What does your data layer look like? Where are your users geographically? How much Docker experience does your team have? And what's your monthly infrastructure budget? The answers map surprisingly cleanly to one of these three platforms.
For a typical early-stage SaaS team building with Node.js and PostgreSQL, we usually recommend starting on Railway for speed, then migrating to Render once you need production Postgres with PITR and predictable billing. Teams building real-time or latency-sensitive products (multiplayer games, financial dashboards, collaborative editors) often go straight to Fly.io with an external managed database.
We also handle the migration itself, reconfiguring environment variables, setting up CI/CD pipelines, and ensuring zero-downtime database transfers. It's the kind of work that takes a team a weekend but takes us a few hours because we've done it dozens of times.
Need help choosing or migrating your deployment platform? Get a free architecture review, we'll assess your stack and recommend the best fit.
Which Platform Fits Your Stage?
Stop asking "which is best" and start asking "which is best for where I am right now."
| If You Need... | Choose | Why |
|---|---|---|
| Fastest prototype to production | Railway | Usage-based pricing, best DX, deploy in 2 minutes |
| Production SaaS with managed infra | Render | Managed Postgres with PITR, autoscaling, predictable billing |
| Global latency-sensitive product | Fly.io | 18 regions, Docker-native, true scale-to-zero |
| Heroku replacement | Render | Closest DX to Heroku, managed services, flat-rate billing |
| Team with Docker expertise | Fly.io | Full control, cheapest at scale, GPU support |
| Solo developer on a budget | Railway | Pay only for actual usage, $5/mo Hobby plan |
| Internal tools with sporadic traffic | Fly.io | Scale-to-zero saves money on idle apps |
Here's the graduation path most teams follow: Start on Railway when you're iterating fast and don't want to think about infrastructure. Move to Render when you need production Postgres, preview environments, and your team is growing. Move to Fly.io when latency matters globally or you've outgrown single-region deployment.
The key trigger for each move? If you find yourself needing PITR or read replicas, it's time for Render. If you find yourself wishing your app was closer to users in Asia or Europe, it's time for Fly.io.
If AI features are on your roadmap, that is our specialty: Techsy's AI integration team takes LLM systems from prototype to production. Two caveats worth flagging before you pick a platform for an AI workload: none of Railway, Render, or Fly.io is built for running an LLM inference server specifically, if that's your use case, our guide to deploying an LLM on Modal covers the GPU-specific setup these three platforms don't. And if what you actually need is ephemeral, sandboxed code execution for an AI agent rather than an always-on web service, that's a different category entirely, look at purpose-built sandbox runtimes like E2B or Daytona instead of a general application host.
Frequently Asked Questions
Is Railway better than Render?
For prototyping and side projects, yes, Railway's usage-based pricing and instant deploys make it the better choice when you're iterating fast. For production SaaS with real customer data, Render's managed Postgres with PITR and predictable billing makes it the stronger pick. It depends entirely on your stage.
Which is cheaper: Railway, Render, or Fly.io?
Railway is cheapest for hobby use (you only pay for what you consume). Fly.io is cheapest at scale thanks to $0.02/GB egress in North America and Europe. Render is the most expensive in absolute terms but the most predictable, no surprise bills. Check the pricing table above for real estimates at four traffic tiers.
Does Railway have a free tier?
No. Railway removed its free tier in 2023. New accounts get a one-time $5 trial credit. After that, the Hobby plan is $5/month with usage-based billing on top. Render still offers a limited free tier (with cold starts). Fly.io's old $5/month free allowance is gone too for new accounts, new organizations only get a short trial (2 VM hours or 7 days) and then need a credit card on file, so of the three, only Render has an ongoing free option in 2026.
What are Render's cold start problems?
Render's free tier services spin down after 15 minutes of inactivity. The first request after spin-down takes 30-60 seconds to respond, unacceptable for any user-facing app. Paid plans ($7/month and up) stay warm and don't have this issue.
How does Fly.io pricing work?
Fly.io bills per VM-second for Machines, per GB/month for Volumes, and per GB for egress. A basic shared-cpu-1x VM with 256MB RAM costs roughly $2.02/month running 24/7. The complexity comes from billing each component separately, VMs, persistent storage, IPv4 addresses, and bandwidth all have their own rates. The common developer complaint is that it "requires a spreadsheet" to predict monthly costs.
Can Railway handle production traffic?
Yes, Railway handles production workloads and many startups run on it. The main limitation is its containerized databases, no PITR, no read replicas, no automated failover on the default tier. Railway has an experimental HA Postgres upgrade (launched March 2026) that adds automatic failover, but Railway itself warns it's not production-ready yet. For production Postgres today, either use Railway for compute with an external managed database (like Neon or Supabase), or consider Render.
What is the best Heroku alternative in 2026?
Render is the closest Heroku replacement, managed services, flat-rate billing, and a similar developer experience. Railway is simpler and cheaper for small projects. Fly.io offers more control and global reach but requires Docker knowledge. Since Heroku shifted to sustaining engineering in February 2026, all three have seen increased adoption from migrating teams.
Railway vs Render for Node.js?
Both handle Node.js well. Railway is faster to deploy thanks to Railpack's automatic runtime detection, push your repo and it figures out the build. Render requires a bit more configuration but offers better production infrastructure once you're past the prototype stage. For a Node.js API with Postgres, Railway gets you running faster; Render keeps you running safer.
Does Fly.io support managed databases?
Fly Postgres exists but Fly.io explicitly states it's not a managed database. If Postgres crashes due to memory or disk issues, you're responsible for recovery. They can't provide database support. For managed Postgres on Fly.io infrastructure, most teams use Neon, Supabase, or PlanetScale alongside Fly.io compute.
Can I migrate between Railway, Render, and Fly.io?
Yes. All three deploy from Docker images or Git repos, so your application code doesn't change. The migration work involves reconfiguring environment variables, moving databases (export/import), updating custom domains and DNS, and adjusting CI/CD pipelines. Budget a weekend for a small project, or a sprint for anything with production data and multiple services.
Final Verdict: Railway vs Render vs Fly.io
| Category | Winner | Runner-Up | Why |
|---|---|---|---|
| Pricing (Hobby) | Railway | Fly.io | Pure usage-based, pay nothing when idle |
| Pricing (Scale) | Fly.io | Railway | $0.02/GB egress in NA/EU, cheapest at high traffic |
| Developer Experience | Railway | Render | Fastest deploy, best CLI, zero config |
| Managed Databases | Render | Railway | PITR, read replicas, automated backups (Railway's HA option is still experimental) |
| Global Deployment | Fly.io | Render | 18 regions vs Render's 5, native multi-region |
| Scale-to-Zero | Fly.io | , | Only platform with true scale-to-zero on paid |
| Team Features | Render | Railway | PR preview environments with full DB copies, now $25/mo flat instead of per-seat |
| Overall | Depends on stage | , | See framework below |
Start with Railway when you're building. Move to Render when you're growing. Choose Fly.io when you're scaling globally. That's not a cop-out, it's genuinely the best advice. Each platform dominates at a specific stage of your company's growth.
All three are solid, actively developed platforms with responsive communities. The worst decision is spending weeks evaluating when you could be shipping. Pick the one that matches your current stage, deploy your app, and revisit in six months if your needs change.
Sources
- Railway Pricing
- Railway Pricing Plans
- Railway Deployment Regions
- Railway Changelog: Highly Available Postgres (Mar 2026)
- Render Pricing
- Render New Workspace Plans
- Render Changelog: Updated Plans for Render Workspaces
- Render Regions
- Render Free Tier Documentation
- Render Managed Postgres Documentation
- Render Postgres Flexible Plans
- Render Preview Environments
- Fly.io Pricing
- Fly.io Billing
- Fly Postgres, What You Should Know
- Fly.io Regions Reference
- Heroku: An Update on Heroku (Feb 2026)