Skip to main content
Tech Stack & Architecture

How to Deploy a SaaS on Vercel, Railway or AWS, and Build Real-Time Features Efficiently

By Obaid Tariq, Founder & Lead Engineer · Published

The short answer

To deploy a SaaS cost-effectively, match the platform to the workload: Vercel suits Next.js front ends and request/response APIs, Railway suits always-on containers, workers and databases with simple usage-based billing, and AWS suits teams that need fine-grained control, compliance or credits and can carry the operational work. Many products combine them. For real-time features, start with the simplest transport that works (polling, then server-sent events), use WebSockets only for genuinely two-way, low-latency interaction, and consider a managed service such as Supabase Realtime, Pusher or Ably before running your own socket fleet.

What is a cost-effective, reliable way to deploy a production SaaS using platforms such as Vercel, Railway or AWS?

For most early SaaS products, a managed platform is cheaper overall than AWS once you count engineering time: Vercel for a Next.js app, Railway for always-on services and workers, and a managed PostgreSQL database. Move workloads to AWS (or another hyperscaler) when you need its compliance controls, networking, credits or price at scale, and use containers so the move is not a rewrite. Reliability comes mostly from practices (CI/CD, preview environments, migrations, backups, monitoring), not from which logo is on the bill.

How each platform charges and behaves

Exact prices change often, so check each pricing page. What matters for planning is the cost shape: what you pay for, and what makes the bill grow.

Vercel, Railway and AWS compared by model and cost shape, at the time of writing
PlatformCompute modelWhat you pay forBest forWatch out for
VercelFunctions on Fluid compute, plus CDN for static assetsPer Vercel's docs: Active CPU, Provisioned Memory and Invocations for functions, plus data transferNext.js front ends, marketing pages, APIs with short requestsFunction maximum durations; long jobs and persistent processes belong elsewhere
RailwayContainers built from a repo or Docker image, running continuously unless you enable Serverless sleepingPer Railway's docs: a base subscription that counts towards metered RAM, CPU, network egress and volume storageAPIs, background workers, cron jobs, WebSocket servers, small databasesAlways-on services cost money while idle unless you enable Serverless sleeping
AWSLambda functions, ECS on Fargate (including ECS Express Mode), EC2 and managed databasesEach underlying resource: compute time, load balancers, NAT, storage, data transferCompliance-heavy customers, complex networking, large scale, existing creditsMore services to configure and secure; easy to leave costly resources running

Platform facts worth knowing

  • Vercel: functions run on Fluid compute, which Vercel's docs say is the default for projects created on or after 23 April 2025. Vercel's documentation lists maximum function durations of 300 seconds on Hobby and a default of 300 seconds with a maximum of 800 seconds on Pro and Enterprise, with a longer 1,800-second limit in beta for supported runtimes.
  • Railway: services are deployed from a code repository or Docker image, joined to a private network inside the project, and can mount volumes. Railway's docs say services run continuously unless you enable its Serverless feature (formerly App Sleeping), which sleeps a service after a period without outbound traffic; the first request after sleep waits for a cold boot and may receive a 502.
  • AWS App Runner: AWS's documentation says App Runner is no longer open to new customers and recommends Amazon ECS Express Mode instead. ECS Express Mode takes a container image and two IAM roles and provisions a Fargate service, an Application Load Balancer, auto scaling and networking; AWS says there is no extra charge beyond the resources it creates.
  • AWS Lambda: Lambda's documentation sets the maximum timeout at 900 seconds (15 minutes), so very long jobs need containers or a queue-based design.

A cost-effective default architecture

  1. Web app on Vercel (or another Next.js-capable host): static marketing pages, Server Components and short API routes.
  2. Workers on Railway (or ECS): queue consumers, scheduled jobs, PDF generation, imports, anything that runs longer than a request.
  3. Managed PostgreSQL (Supabase, Neon or AWS RDS) with automated backups and a tested restore. See Supabase vs Neon.
  4. Object storage for user files, served through signed URLs.
  5. Managed services for the rest: email, error tracking, uptime monitoring, and a real-time provider if you need one.

Keep the app containerisable even if you start on Vercel. The Next.js deployment docs say a Node.js server or Docker container supports all Next.js features, so moving to Railway, ECS or another host stays a deployment change rather than a rewrite.

Reliability comes from the pipeline

  • CI on every pull request: type-check, lint, unit tests and a build. Block merges on failure.
  • Preview environments per pull request, ideally with a database branch, so reviewers test real behaviour.
  • Migrations as a pipeline step, run with a direct database connection before the new code receives traffic, and written to be backwards-compatible.
  • Health checks and fast rollback. Confirm how your platform rolls back to a previous deployment, and practise doing it before you need it.
  • Separate environments for production and staging, with separate secrets and databases.
  • Monitoring: error tracking, structured logs, uptime checks and alerts that reach a person.
  • Backups you have restored at least once.

For the day-to-day workflow around this, see our guide to a modern web development workflow, and for launch readiness, the SaaS launch checklist.

Controlling hosting costs

  • Set spend alerts or limits on every platform from day one.
  • Cache static and semi-static pages; on Next.js, prerendered pages served from the CDN avoid function invocations.
  • Move slow work off the request path into workers, so you pay for it once rather than holding open functions.
  • Watch data transfer and image optimisation, which often grow faster than compute.
  • On AWS, tag resources by environment and review idle load balancers, NAT gateways and unattached volumes monthly.

When a different approach makes sense

If your customers require deployment into their own cloud account or region, start with containers and infrastructure as code on AWS, Azure or Google Cloud. If your team already runs Kubernetes well, use it. If your product is a small internal tool, a single container on one platform is enough. If you need help designing or migrating the setup, our web development team does this work; a solo founder can get far with the default above and the platforms' own templates.

How do I implement real-time features such as WebSockets and live updates efficiently?

Use the simplest transport that meets the need: polling for data that changes every few seconds or less often, server-sent events for one-way streams such as notifications or AI output, and WebSockets for two-way, low-latency interaction such as chat, presence or collaborative editing. Keep shared state in a database or pub/sub service rather than server memory, design for reconnects, and consider a managed real-time service before running your own WebSocket servers.

Choose the transport

Polling vs server-sent events vs WebSockets
TransportDirectionGood forCosts and limits
PollingClient asks on a timerDashboards, job status, data that can be a few seconds staleWasted requests when nothing changes; simplest to build, cache and scale
Server-sent events (SSE)Server to client over HTTPNotifications, activity feeds, progress bars, streaming AI responsesOne-way only; MDN notes a limit of 6 open connections per browser and domain without HTTP/2
WebSocketsBoth ways, persistentChat, presence, multiplayer, collaborative editing, live cursorsStateful connections to scale, authenticate, reconnect and fan out
Managed pub/subBoth ways via a providerAny of the above without running socket serversPer-connection or per-message pricing; another vendor

SSE is underused. MDN's guide explains that the browser's EventSource reconnects automatically and that the server can set the reconnection delay with a retry field, and Vercel's own guidance recommends SSE when data only flows from server to client. MDN adds that over HTTP/2 the number of simultaneous streams is negotiated between browser and server, with a default of 100, so serve SSE over HTTP/2 where you can.

Where WebSockets can run

  • Vercel Functions: Vercel's changelog says WebSocket support entered public beta on 22 June 2026, on all plans, and requires Fluid compute. Each connection is pinned to one function instance and closes when the function reaches its maximum duration, so clients must reconnect, and Vercel recommends keeping rooms, presence and pub/sub coordination in an external store such as Redis. Next.js uses a helper from the @vercel/functions package to upgrade the connection. As it is a beta, treat behaviour and APIs as subject to change.
  • Railway or ECS containers: a long-running Node.js, Go or Elixir process can hold connections indefinitely. You still need a shared pub/sub layer (for example Redis) once you run more than one instance.
  • AWS API Gateway WebSocket APIs: a managed connection layer that routes messages to backend integrations such as Lambda functions. AWS's quotas page lists a maximum connection duration of 2 hours, an idle timeout of 10 minutes, a 128 KB message payload with 32 KB frames, and a default of 500 new connections per second per account and Region.

Managed real-time services

For many SaaS products, running WebSocket infrastructure is not where your value lies. Managed options:

  • Supabase Realtime offers Broadcast (low-latency messages between clients), Presence (who is online) and Postgres Changes (stream database changes). Its docs explain that Postgres Changes authorises every event against each subscriber on a single thread, so throughput depends on the number of subscribers, and suggest switching to Broadcast beyond roughly 3,000 concurrent subscribers on the same changes. Private channels are authorised with RLS policies on realtime.messages, and you must disable public access in Realtime settings to enforce them.
  • Pusher Channels is a hosted WebSocket pub/sub service with private and presence channels; its plans are tiered by daily messages and concurrent connections.
  • Ably describes itself as a pub/sub platform with message delivery guarantees, so your code does not handle missed, duplicated or out-of-order messages.

Design rules for efficient live updates

  1. Send events, then fetch. Push a small message ("invoice 123 changed") and let the client refetch through your normal, authorised API. This keeps permission logic in one place.
  2. Authorise on subscribe and on every server-originated message. Channel names should include the tenant and resource, and the server should check membership before joining; see multi-tenant SaaS architecture.
  3. Never rely on server memory for shared state. Use the database or a pub/sub store, because connections land on different instances.
  4. Handle reconnects. Use exponential back-off, resubscribe, and fetch anything missed since the last event ID.
  5. Batch and throttle. Coalesce rapid changes (typing, cursor moves) on the client and server.
  6. Measure connection counts and message rates, since they drive cost on every platform and provider.

Worked examples

Suggested transport for common SaaS real-time features
FeatureSuggested approach
Background job progressPolling every few seconds, or SSE from the job status endpoint
In-app notificationsSSE or a managed channel per user; fall back to polling
Streaming AI responsesSSE or a streamed HTTP response
Team chat or comments with typing indicatorsWebSockets via a managed service or Supabase Realtime Broadcast and Presence
Collaborative document editingWebSockets with a CRDT library and a dedicated sync server or provider
Live dashboard of database changesPolling at first; Postgres Changes or Broadcast from the database as usage grows

When a different approach makes sense

If updates are rare and nobody watches the screen, email or a notification badge refreshed on navigation is enough. If you need offline-first sync for a mobile or desktop app, a sync engine built for that purpose is usually better than hand-written socket code. For AI products, streaming responses with SSE covers most needs; see our guide to LLM integration patterns.

Frequently asked questions

Can I run WebSockets on Vercel?

Yes, in beta. Vercel's documentation says WebSocket support for Vercel Functions entered public beta on 22 June 2026, on all plans, with Fluid compute required. Connections close when the function reaches its maximum duration, so clients need reconnect logic and shared state belongs in an external store.

Is AWS cheaper than Vercel or Railway?

Raw compute on AWS can be cheaper at scale, but you also pay for load balancers, networking, monitoring and the engineering time to configure and secure them. For small teams a managed platform is often cheaper overall; compare total cost, including people, for your actual workload.

Should I still use AWS App Runner?

Not for new projects. AWS's documentation says App Runner is no longer open to new customers, though existing customers can keep using it, and recommends Amazon ECS Express Mode as the alternative for simple container deployments.

When should I use server-sent events instead of WebSockets?

Use server-sent events when data only flows from the server to the browser, such as notifications, progress updates or streamed AI output. They work over ordinary HTTP, reconnect automatically and are simpler to secure and scale than WebSockets.

Sources

  1. Vercel changelog: WebSocket support is now in public beta — WebSocket support for Vercel Functions entered public beta on 22 June 2026. Accessed 19 October 2026.
  2. Vercel Docs: WebSockets — WebSockets in beta on all plans; Fluid compute required; connection pinning; reconnect on maximum duration; external state; Next.js upgrade helper; billing under function pricing. Accessed 19 October 2026.
  3. Vercel Knowledge Base: Do Vercel Functions support WebSocket connections? — Public beta date of 22 June 2026; duration limits by plan; SSE recommendation for server-to-client data; billing by Active CPU, Provisioned Memory and Invocations. Accessed 19 October 2026.
  4. Vercel Docs: Configuring maximum duration — Maximum function durations by plan. Accessed 19 October 2026.
  5. Railway Docs: Pricing plans — Base subscription plus metered RAM, CPU, egress and volume storage; included usage. Accessed 19 October 2026.
  6. Railway Docs: Serverless (App Sleeping) — Services run continuously unless Serverless is enabled; sleep after inactivity; cold boot and possible 502 on first request. Accessed 19 October 2026.
  7. Railway Docs: The basics — Services from repositories or Docker images, private networking, volumes. Accessed 19 October 2026.
  8. AWS Docs: AWS App Runner availability change — App Runner closed to new customers; recommendation of ECS Express Mode; what Express Mode provisions; no additional charge. Accessed 19 October 2026.
  9. AWS Docs: Amazon ECS Express Mode — ECS Express Mode overview. Accessed 19 October 2026.
  10. AWS Docs: Lambda function timeout — Maximum Lambda timeout of 900 seconds. Accessed 19 October 2026.
  11. AWS Docs: API Gateway WebSocket quotas — 2-hour connection duration, 10-minute idle timeout, 128 KB payload, 32 KB frames, 500 new connections per second default. Accessed 19 October 2026.
  12. Next.js Docs: Deploying — Node.js server and Docker deployments support all Next.js features. Accessed 19 October 2026.
  13. Supabase Docs: Realtime — Broadcast, Presence and Postgres Changes. Accessed 19 October 2026.
  14. Supabase Docs: Postgres Changes — Per-subscriber authorisation, single-thread processing, Broadcast recommended beyond roughly 3,000 concurrent subscribers. Accessed 19 October 2026.
  15. Supabase Docs: Realtime Authorization — RLS policies on realtime.messages, private channels, disabling public access. Accessed 19 October 2026.
  16. Pusher Channels — Hosted WebSocket pub/sub with private and presence channels; plans tiered by messages and connections. Accessed 19 October 2026.
  17. Ably Docs: Platform — Pub/sub platform with message delivery guarantees. Accessed 19 October 2026.
  18. MDN: Using server-sent events — Six-connection limit per browser and domain without HTTP/2; automatic reconnection; retry field. Accessed 19 October 2026.

Recommendations without a source are AI Dev Planner’s own engineering opinion. Platform features and prices change; check the linked pages for the current position. Found an error? See our corrections policy.

Related guides

Browse all 50 questions in the SaaS & web development guide.

Need a deployment plan you can trust?

Tell us about your app, traffic and customers, and we will suggest where each part should run and how to keep the bill predictable.

Plan your deployment SaaS development services