Application hosting and deployment: the agent answers

I’d use **Render**, assuming the Node API is a conventional Express/Fastify/Nest service and you want to migrate it largely unchanged.

Render fits this particular shape well:

- Connect the repository and deploy production automatically after CI passes.
- Run React as a CDN-backed static site and the Node API as a managed web service.
- Define both in a version-controlled `render.yaml` Blueprint.
- Automatically create an isolated copy of the frontend, API, and optionally databases for every pull request, then destroy it when the PR closes. [Render preview environments](https://render.com/docs/preview-environments)
- Run migrations through a pre-deploy command and deploy without maintaining or patching a VM. [Render deployment workflow](https://render.com/docs/deploys)

The main reason I’d choose it over Vercel is the API. Render runs an ordinary, persistent Node process, so moving an existing API is usually configuration rather than architectural work.

What I weighed:

| Platform | Why I considered it | Why it wasn’t my default |
|---|---|---|
| **Vercel** | Best-in-class React/Next.js previews and Git workflow | A traditional API must fit the function model. Function duration, 4.5 MB payload, bundle, filesystem, and connection constraints can force changes. [Vercel limits](https://vercel.com/docs/functions/limitations) |
| **Railway** | Very pleasant deployment experience for conventional services | Good alternative, but I’d favor Render’s Blueprint-based, full-stack preview-environment workflow for this requirement |
| **Fly.io** | Excellent for Docker, regional placement, WebSockets, and low-level control | PR environments require GitHub Actions and more operational configuration. It removes the physical VM but still feels closer to infrastructure ownership. [Fly review apps](https://fly.io/docs/blueprints/review-apps-guide/) |
| **Cloudflare Workers/Pages** | Minimal operations, global edge execution, inexpensive at scale | Usually requires adapting a Node server to the Workers runtime; not my first choice for a low-ceremony migration |
| **AWS/GCP/Azure managed containers** | Maximum flexibility and ecosystem depth | More IAM, networking, deployment, observability, and cost-management machinery than a single developer should inherit |

There are two important catches with Render:

- Full Blueprint preview environments require a **Pro plan or higher**, and preview resources are billed like normal resources, prorated by the second. Configure smaller preview instances and automatic expiry.
- Preview databases start empty; production data is not copied. Add migrations and safe seed data through the preview initialization hook.

I’d structure the repository so `render.yaml` declares:

- `web`: React static site
- `api`: paid Node web service with health check and pre-deploy migration
- managed Postgres/Redis if needed
- `previews.generation: automatic`
- cheaper preview plans plus `expireAfterDays`
- deploy only after required CI checks pass

One qualification: if the “Node API” is already just short-lived stateless HTTP handlers—with no large uploads, long jobs, persistent connections, or local-disk assumptions—I’d choose **Vercel** instead, because its preview experience is even smoother. Vercel creates deployments automatically from commits and pull requests. [Vercel Git deployments](https://vercel.com/docs/deployments/overview)

“No server to patch” still leaves application ownership: Node versions, npm dependencies, database migrations, secrets, monitoring, backups, and rollback testing remain yours. Render removes host-OS administration; it does not remove software maintenance.

I’d use **Render**, assuming the Node API is a conventional long-running process—Express/Fastify/Nest, background workers, perhaps Postgres or Redis—and you want to move it largely unchanged.

Render fits the operating model you described:

- Connect the Git repository and deploy production automatically from `main`.
- Define the React app, Node API, workers, databases, and environment groups in a version-controlled `render.yaml`.
- Create an isolated environment for each pull request, update it on every push, and destroy it when the PR closes.
- Run the API as an ordinary Node web service rather than converting it into serverless functions.
- Let Render operate and patch the underlying infrastructure. You remain responsible for application dependencies and database migrations.

Its full [preview environments](https://render.com/docs/preview-environments) can clone an entire Blueprint, including services and datastores—not merely produce a frontend URL. Render also supports cheaper instance types and initialization hooks for preview databases. One caveat: full preview environments require a **Pro plan or higher**, and each preview resource is billed while running. I would set previews to expire after a few inactive days and seed them with synthetic data.

What I weighed:

- **Railway:** The closest alternative and arguably the fastest initial setup. Its [PR Environments](https://docs.railway.com/guides/preview-deployments-with-pr-environments) replicate frontend, backend, networking, variables, and databases automatically. Focused previews can deploy only changed services, although that feature is currently marked beta. I’d choose Railway instead if minimum configuration and usage-based economics mattered more than having the stack declared cleanly in one infrastructure file.

- **Vercel:** Excellent React deployment experience and automatic previews on every branch or PR. I would pick it immediately for a frontend-only or Next.js application. For an existing general-purpose Node server, however, it introduces a serverless execution model with function-duration, payload, bundle, and WebSocket constraints ([Git deployments](https://vercel.com/docs/git), [function limits](https://vercel.com/docs/functions/limitations)). Hosting the frontend there and the API elsewhere is valid, but gives a one-developer project two platforms, two environment-variable systems, and less faithful full-stack previews.

- **Fly.io:** Runs containers with considerable flexibility and supports [PR review apps](https://www.fly.io/docs/blueprints/review-apps-guide/). But previews are assembled through GitHub Actions, tokens, TOML configuration, and optional provisioning logic. It removes the physical VM, yet retains more infrastructure work than your “no small ceremony” goal calls for.

- **AWS/GCP/Azure container services:** Capable and defensible when compliance, private networking, or an existing cloud estate matters. For this team size, IAM, registries, CI workflows, load balancing, secrets, and per-PR cleanup would recreate much of the ceremony in another form.

My target layout would be one repository with `frontend/`, `api/`, and a `render.yaml`; production deploys only after CI passes; each PR gets a static frontend, API service, and disposable database; migrations run as a release step; persistent user uploads move to object storage. That gives you “merge is the deployment process” without forcing an architectural rewrite.

I’d use **Render**, assuming the Node API is a conventional long-running Express/Fastify/Nest service and the React app builds to static files.

Render is the best fit because it removes the VM without forcing an architectural rewrite:

- The Node API runs as a managed web service.
- The React build runs as a static site behind a CDN.
- Pushes to the production branch build and deploy automatically.
- Each pull request can get an isolated URL, updated on every commit and removed when the PR closes.
- A `render.yaml` Blueprint can describe the frontend, API, workers, databases, health checks, and environment variables in one repository.

Render explicitly supports Node/Express services and Git-based automatic deployments. Its full preview environments can clone all services and datastores defined in a Blueprint, although that feature requires the Pro plan. [Web services documentation](https://render.com/docs/web-services), [preview environments](https://render.com/docs/preview-environments), [Blueprint specification](https://render.com/docs/blueprint-spec).

What I weighed:

| Platform | Why I didn’t choose it first |
|---|---|
| **Vercel** | Excellent React and preview experience, and my first choice for a frontend-only application. But moving an existing persistent Node server into functions can expose differences around process lifetime, local disk, WebSockets, background work, payload size, and request duration. [Function limits](https://vercel.com/docs/functions/limitations) |
| **Railway** | Very pleasant developer experience and a strong runner-up. I’d seriously consider it for a container-centric team, but Render’s static-site/API split and Blueprint-based full-stack previews are a slightly cleaner match here. |
| **Heroku** | Proven and easy to operate. Review Apps are mature, but require Pipelines, GitHub integration, and `app.json`; preview dynos and add-ons are billed like regular resources. [Heroku Review Apps](https://devcenter.heroku.com/articles/github-integration-review-apps) |
| **Fly.io** | Great when regional placement, WebSockets, or low-level runtime control matter. PR environments are assembled through GitHub Actions, tokens, and configuration, leaving more platform engineering with your developer. [Fly review apps](https://fly.io/docs/blueprints/review-apps-guide/) |
| **AWS/GCP/Azure containers** | More flexibility, but excessive IAM, networking, deployment, logging, and infrastructure surface area for a one-developer application. You would remove SSH patching while creating a different operations ceremony. |
| **Cloudflare** | Attractive if the API already suits an edge/serverless runtime. Less attractive as a lift-and-shift destination for an ordinary Node server. |

The main design decision is preview data. I would give each PR an empty, migrated, optionally seeded database—not a connection to production. Render’s full preview environments create fresh datastores rather than copying production data. If a database per PR is too expensive, use automatic service previews with one dedicated non-production database and an isolated schema per PR. Individual preview services are billed at the base service’s rate, prorated by the second. [Service preview behavior and billing](https://render.com/docs/service-previews).

My initial setup would be:

1. Put the React static site and Node API in one `render.yaml`.
2. Deploy production only from the protected main branch.
3. Require tests before merge.
4. Enable automatic Blueprint preview environments.
5. Run migrations and seed synthetic data during preview initialization.
6. Add health checks, rollback expectations, log retention, backups, and spending alerts.
7. Keep uploads out of local disk—use object storage.

That gets you from “someone deploys the VM” to “merge a reviewed PR and the platform releases it,” while keeping the existing Node application model largely intact.

I’d use **Render**.

For an existing Node API plus React frontend, it gives the cleanest path from “VM maintained by one developer” to a managed, Git-driven platform without forcing an immediate serverless rewrite:

- Deploy the React app as a static site on its global CDN.
- Deploy the Node API as a managed web service.
- Merge to `main` → automatic production deployment.
- Open or update a pull request → isolated preview services with their own URLs.
- Define the stack in `render.yaml`, including services, environment variables, databases, workers, and preview behavior.
- Render handles TLS, process supervision, health checks, scaling, rollbacks, and host maintenance. There is no VM for your team to patch.

Render supports both lightweight previews of individual services and full preview environments that reproduce multiple services and datastores. Full preview environments require a Pro plan, are updated with every PR commit, and are destroyed when the PR closes. [Render web services](https://render.com/docs/web-services), [preview environments](https://render.com/docs/preview-environments).

### What I weighed

| Platform | Why it was tempting | Why I wouldn’t choose it first here |
|---|---|---|
| **Vercel** | Excellent React experience; automatic deployments and unique PR URLs are exceptionally polished. [Git deployments](https://vercel.com/docs/git) | Best if the API can become functions. A conventional Express server may need adaptation, and functions have duration, bundle, filesystem, and connection-model constraints. [Function limits](https://vercel.com/docs/functions/limitations) |
| **Netlify** | Strong static frontend hosting and automatic deploy previews. [Deploy previews](https://docs.netlify.com/deploy/deploy-types/deploy-previews/) | Similar serverless pressure for the API; less natural than Render for an unchanged, continuously running Node service. |
| **Cloudflare Pages + Workers** | Great global performance and inexpensive edge execution; Pages creates PR preview URLs automatically. [Preview deployments](https://developers.cloudflare.com/pages/configuration/preview-deployments/) | Workers are not a drop-in conventional Node server. Node compatibility has improved, but architecture and runtime assumptions still deserve review. |
| **Railway/Fly.io** | Flexible application hosting, especially for containers. | More operational choices, and the full-stack PR-preview workflow is less turnkey than Render’s Blueprint environments. |
| **AWS/GCP/Azure** | Maximum control and breadth. | Too much infrastructure and configuration for a single-developer team whose primary goal is eliminating release ceremony. |

The important caveat is the database: a frontend URL alone is not a meaningful preview if every PR talks to production data. I would configure Render preview environments with a fresh preview database, run migrations automatically, and seed sanitized test data. Preview resources are billed like ordinary resources, prorated by usage, so I’d use smaller preview instance types and automatic expiry.

If the Node API is already stateless, short-lived, and easy to express as functions, I’d reverse the choice and use **Vercel** for the whole application. Otherwise, Render wins because it removes the server without making you redesign the API first.

I’d use **Render**, assuming the Node API is a conventional long-running Express/Fastify/Nest service.

Render maps cleanly onto what you already have:

- React becomes a managed static site behind a CDN.
- The API becomes a managed Node web service, without converting it to serverless functions.
- Pushes to the production branch automatically build and deploy.
- A `render.yaml` Blueprint keeps the frontend, API, environment configuration, and any managed database described together.
- Each pull request can create an isolated copy of the full application, keep it updated on subsequent commits, and delete it when the PR closes. Full preview environments require a Pro plan. [Render Git integration](https://render.com/docs/github), [preview environments](https://render.com/docs/preview-environments), [Node web services](https://render.com/docs/web-services)

The important distinction is that I’d enable a **Blueprint preview environment**, not merely separate frontend and API previews. That lets each preview frontend point to its matching preview API. If there is a database, provision a disposable preview database and seed it with synthetic data—never let PR environments inherit production credentials or production data.

What I weighed:

| Platform | Why it was attractive | Why I didn’t choose it first |
|---|---|---|
| **Railway** | Probably the closest alternative. Excellent full-stack workflow; PR environments reproduce services, networking, and variables and disappear when the PR closes. [Railway PR environments](https://docs.railway.com/environments) | I slightly prefer Render’s explicit Blueprint model for a small team that wants infrastructure configuration reviewed in Git. I’d choose Railway instead if its developer experience or usage pricing proved better for this particular workload. |
| **Vercel** | Best-in-class React/Next.js preview experience and very polished Git integration. | A traditional Node server must usually be adapted to functions. Functions have execution, payload, filesystem, and WebSocket constraints; for example, Vercel documents a 4.5 MB request/response limit and no WebSocket-server support. [Vercel function limits](https://vercel.com/docs/functions/limitations), [platform limits](https://vercel.com/docs/limits) |
| **Heroku** | Mature, predictable PaaS with automatic GitHub deploys and disposable Review Apps. [Heroku Review Apps](https://devcenter.heroku.com/articles/github-integration-review-apps) | Still sound, but usually a less compelling price/developer-experience choice for a new small application than Render or Railway. |
| **Fly.io** | Strong when you need Docker control, persistent processes, special networking, or regional placement. | Continuous deployment and review apps are more GitHub-Actions-driven, leaving more infrastructure machinery for this developer to own. [Fly deployment model](https://fly.io/docs/launch/), [review-app guide](https://fly.io/docs/blueprints/review-apps-guide/) |
| **Cloudflare Workers/Pages** | Excellent edge delivery and frontend previews. | Moving an existing Node API to the Workers runtime may require compatibility work; it is an architectural migration, not merely replacing the VM. |
| **AWS/GCP/Azure container services** | Maximum flexibility and ecosystem depth. | Too much IAM, networking, registry, CI, observability, and preview-environment assembly for the stated objective. |

Before committing, I’d run a short proof of concept checking the API’s background jobs, WebSockets, uploads/local-disk assumptions, database migrations, region requirements, and expected preview costs. If those are ordinary web-service needs, Render is the lowest-ceremony answer. If the API is already stateless and function-shaped, I’d revisit Vercel; if it is container-heavy or needs unusual networking, I’d move toward Railway or Fly.io.

I’d use **Render** for this application.

It fits the existing architecture without forcing a redesign:

- Deploy the React build as a static site on its CDN.
- Run the Node API as a managed web service.
- Connect the repository so pushes to the production branch deploy automatically.
- Define both services in a version-controlled `render.yaml`.
- Enable automatic preview environments so every pull request receives its own frontend and API URLs. Render updates them on subsequent commits and removes them when the PR closes. It can also provision isolated preview databases. [Render deployment docs](https://render.com/docs/github) and [preview-environment docs](https://render.com/docs/preview-environments).

Nobody manages or patches a VM. Render still runs the API in a containerized instance, but the operating system and host are the platform’s responsibility.

What I weighed:

- **Vercel:** Best frontend and preview experience, and an excellent choice if the API is already stateless and function-shaped. An existing Express/Fastify server may need adaptation, however, and functions have execution-duration and filesystem constraints. I wouldn’t introduce that migration just to solve deployment. [Vercel deployments](https://vercel.com/docs/deployments/overview) and [function limits](https://vercel.com/docs/functions/limitations).
- **Netlify:** Very strong React hosting and automatic deploy previews. Like Vercel, it is most natural when backend endpoints fit its functions model; less attractive for an unchanged, conventional Node server. [Netlify Deploy Previews](https://docs.netlify.com/deploy/deploy-types/deploy-previews/).
- **Railway:** Probably the closest runner-up. It supports full Node services and automatically provisioned PR environments. I’d choose it if its developer experience or usage-based pricing suited the team better; Render’s Blueprint and complete preview-environment story is the slightly clearer default here. [Railway PR environments](https://docs.railway.com/guides/preview-deployments-with-pr-environments).
- **Cloudflare Pages/Workers:** Excellent edge platform, but Workers expose only a subset of Node compatibility. That can turn a hosting change into application-porting work. [Cloudflare Node compatibility](https://developers.cloudflare.com/workers/runtime-apis/nodejs/).
- **AWS Amplify plus Lambda/API Gateway:** Meets the requirements and can create temporary PR backends, but adds more services, permissions and configuration than one developer should need for this application. [AWS Amplify PR previews](https://docs.aws.amazon.com/amplify/latest/userguide/pr-previews.html).
- **Fly.io:** Capable and flexible, but PR review apps rely on a GitHub Actions workflow and still expose more infrastructure knobs. That works against the goal of reducing ceremony. [Fly review apps](https://www.fly.io/docs/blueprints/review-apps-guide/).

The main caveat is preview cost: Render preview resources are billed like ordinary services, prorated by the second. I’d use smaller preview plans, automatic expiry, and path filters so documentation-only changes do not create an API environment.

Before enabling previews, I’d also separate their data and credentials from production. A preview must never inherit a production database, payment key, OAuth callback configuration, or unrestricted third-party credentials. Render can create fresh preview datastores, but it does not copy production data, so add migrations and sanitized seed data to the preview initialization process.

I’d use **Render**, assuming the Node API is a normal long-running Express/Fastify-style service.

Render fits the whole application without forcing an architectural rewrite:

- Deploy the React build as a static site.
- Deploy the Node API as a managed web service.
- Describe both—and optionally Postgres, Redis, workers, or cron jobs—in a single `render.yaml`.
- Automatically deploy production after CI passes on `main`.
- Create an isolated copy of the application for each pull request, update it on new commits, and delete it when the PR closes.

Render’s preview environments can reproduce all services and managed datastores declared in the Blueprint, rather than previewing only the frontend. They can also use cheaper instance sizes, receive preview-specific environment variables, run initialization or seed commands, and expire automatically. The important catch is that full preview environments require a **Pro plan or higher**, and every preview resource is billed while running. [Render preview-environment documentation](https://render.com/docs/preview-environments)

For production, Render can wait until repository CI checks pass, supports health checks and pre-deploy commands for migrations, and normally performs zero-downtime deployments. [Render deployment documentation](https://render.com/docs/deploys)

### What I weighed

| Platform | Why I considered it | Why I didn’t choose it here |
|---|---|---|
| **Railway** | Very close runner-up. It supports temporary PR environments containing isolated services and automatically removes them when the PR closes. [Railway environments](https://docs.railway.com/environments) | Excellent developer experience, but I slightly prefer Render’s Blueprint-driven, production-oriented model for a small team wanting a boring replacement for a VM. I would happily choose Railway if its pricing or interface appealed more to the developer. |
| **Vercel** | Best-in-class React/frontend previews, especially for Next.js; every deployment gets a preview URL. [Vercel deployments](https://vercel.com/docs/deployments/overview) | Its Node backend model is function-oriented. [Vercel Node runtimes](https://vercel.com/docs/functions/runtimes) A conventional API may need adaptation, particularly around process lifetime, background work, local state, database connections, and request-duration limits. Splitting the frontend onto Vercel and the API elsewhere also makes coordinated PR previews and configuration more complicated. |
| **Heroku** | Mature pipelines and review apps; operationally familiar and capable. [Heroku Review Apps](https://devcenter.heroku.com/articles/github-integration-review-apps) | Still viable, but Render offers a more direct modern full-stack workflow and infrastructure-as-code story for this size of application. |
| **Cloud Run** | Strong isolation, autoscaling, scale-to-zero, managed containers, and Git-triggered production deployments. [Cloud Run continuous deployment](https://docs.cloud.google.com/run/docs/continuous-deployment) | PR environments, frontend hosting, cleanup, IAM, builds, and database wiring require more CI/IaC assembly. Better when the team already uses GCP or needs its networking and compliance capabilities. |
| **Fly.io** | Good for Dockerized apps, regional placement, private networking, and greater runtime control. | Its documented PR-preview path uses GitHub Actions, tokens, and lifecycle automation. [Fly.io review apps](https://fly.io/docs/blueprints/review-apps-guide/) That is more operational machinery than this team is trying to own. |
| **Kubernetes / managed VMs** | Maximum control. | Directly conflicts with “no server for anybody to patch” and would replace the release ceremony with platform maintenance. |

### How I’d structure it

I’d put a `render.yaml` in the repository defining:

1. A static React service.
2. A Node web service with `/health`.
3. A managed database if the application has one.
4. A pre-deploy database-migration command.
5. Automatic PR previews with a short inactivity expiry.
6. Smaller compute plans and non-production credentials for previews.
7. Production deployment only after required CI checks pass.

One subtle point: Render creates new preview datastores but does **not** copy production data. That is desirable for safety, but you need sanitized fixtures or an initialization script. Also keep uploads and application state out of the service filesystem because its default filesystem is ephemeral.

My decision would change if the API were already serverless-friendly—then I’d favor Vercel—or if the company were firmly established on AWS/GCP with strong platform engineering, where Cloud Run or an equivalent cloud-native service could make more organizational sense. For the team described, though, **Render provides the shortest path from hand-maintained VM to genuinely automatic full-stack deployments without introducing a second operations project.**

I’d use **Render**, assuming the Node API is a conventional long-running Express/Fastify-style service rather than something already designed as serverless functions.

The production setup would be:

- React app as a Render Static Site
- Node API as a Render Web Service
- Managed Postgres/Redis if needed
- Everything declared in a repo-level `render.yaml`
- Automatic production deployment from `main`
- Automatic preview environment for every pull request

Render rebuilds and deploys linked services on pushes, supports health checks and zero-downtime replacement, and leaves the last working release running if a new deployment fails. [Render deployment documentation](https://render.com/docs/deploys)

More importantly, its preview environments can clone the entire application topology—not just the frontend—including services, databases, and environment groups. They update with each PR commit and disappear when the PR closes or merges. [Render preview environments](https://render.com/docs/preview-environments)

Why I’d choose it:

- **Minimal application changes.** A normal Node process can keep running normally; it doesn’t need to be decomposed into functions.
- **One platform for both halves.** Frontend, API, workers, cron jobs, and managed data services can live in one declarative Blueprint.
- **Real full-stack previews.** Preview-specific database instances, secrets, plans, initialization commands, and expiry policies are supported.
- **Low operational burden.** Nobody patches a VM, maintains nginx, renews certificates, or scripts deployment rollbacks.
- **An escape hatch.** If the native Node runtime becomes limiting, the same service can deploy from a Dockerfile.

What I weighed against it:

- **Vercel:** My first choice for a Next.js or frontend-heavy application. For an existing conventional Node API, however, moving into request-oriented functions may create needless migration work. Functions have execution and bundle limits, and cannot act as WebSocket servers. [Vercel function limits](https://vercel.com/docs/functions/limitations), [Vercel platform limits](https://vercel.com/docs/limits)
- **Railway:** The closest alternative. It has an excellent developer experience and ephemeral environments. I’d consider it equally seriously if the team prefers its usage-based model or already uses Railway databases.
- **Fly.io:** Excellent for globally distributed, containerized, stateful or WebSocket-heavy services. But PR review apps are assembled through GitHub Actions, leaving more infrastructure machinery for this developer to own. [Fly.io review apps](https://fly.io/docs/blueprints/review-apps-guide/)
- **Cloudflare:** Compelling pricing and edge performance, with unlimited Pages preview deployments, but moving a traditional Node API to Workers can expose runtime compatibility differences. [Cloudflare Pages limits](https://developers.cloudflare.com/pages/platform/limits/)
- **AWS/GCP/Azure:** Maximum flexibility, but too much platform construction for a one-developer application unless organizational requirements demand them.

The main Render caveat is cost: full preview environments require a Pro plan, and preview resources are billed while running. I’d set cheaper preview plans, skip unnecessary workers, and configure automatic expiry. Also, previews must use sandbox credentials and isolated or freshly seeded data—never production databases or live payment/email keys.

This removes server maintenance, but not application maintenance: the developer still owns dependency updates, database migrations, monitoring, backups, and a rollback policy. Render removes the VM ceremony; it does not remove software operations entirely.

I’d use **Render**, assuming the Node API is a conventional long-running Express/Fastify service.

It is the closest replacement for the VM without forcing an architectural rewrite:

- Connect the Git repository and Render builds and deploys the Node service on every push.
- Host the React build as a static site on its CDN.
- Describe both components—and optionally Postgres, Redis, workers, and cron jobs—in a `render.yaml` Blueprint.
- Enable automatic preview environments. Each pull request gets an isolated copy of the declared environment, updates with new commits, and disappears when the PR closes. [Render web services](https://render.com/docs/web-services), [preview environments](https://render.com/docs/preview-environments)

You retain a normal Node process while Render handles the host OS, TLS, routing, health checks, restarts, and deployment machinery. That makes the migration much less risky than immediately converting the API into functions.

What I weighed:

| Platform | Why I considered it | Why it wasn’t my default |
|---|---|---|
| **Render** | First-class Node services, static hosting, Git deploys, infrastructure-as-code, full-stack PR environments | Full-environment previews require Pro, currently $25/month plus compute; preview resources are billed separately. [Plan details](https://render.com/docs/platform-features-by-plan) |
| **Vercel** | Best-in-class React/Next.js deployment experience and automatic preview URLs | Most attractive if the API can naturally become functions. An existing server may need adaptation, and functions have runtime, payload, bundle, and connection constraints. [Git deployments](https://vercel.com/docs/git), [function limits](https://vercel.com/docs/functions/limitations) |
| **Railway** | Very quick container/service deployment and pleasant developer experience | A strong runner-up, but I’d favor Render’s more explicit Blueprint model and documented whole-stack preview lifecycle for this particular requirement |
| **Fly.io** | Excellent Docker portability, regional placement, and more infrastructure control | Review apps depend on GitHub Actions and configuration you own. It removes the physical VM but leaves more operational surface than this one-developer team appears to want. [Fly review apps](https://fly.io/docs/blueprints/review-apps-guide/) |
| **AWS/GCP/Azure container services** | Maximum control, ecosystem depth, and long-term scaling options | IAM, networking, registries, CI/CD, logging, and preview orchestration recreate much of the ceremony you’re trying to eliminate |

Two caveats would affect the final decision:

- Preview databases start empty rather than copying production data. Add migrations plus sanitized seed data through Render’s preview initialization hook.
- Make the application stateless: uploads should go to object storage, sessions to a database/Redis, and secrets into managed environment groups—not the local filesystem.

My target release flow would be: PR opened → Render creates API and frontend previews → tests run against the preview → merge to `main` → production deploys automatically. Protect `main`, require CI and the preview deployment check, and nobody SSHs into production again.

I’d use **Render** for this setup, assuming the Node API is a conventional Express/Fastify-style process and the React frontend is a static SPA.

Render hits the requirements with relatively little platform engineering:

- Connect the Git repository and deploy production automatically from `main`.
- Run the API as a managed web service and the React build as a CDN-backed static site.
- Define the complete stack in a version-controlled `render.yaml`.
- Create an isolated copy of the services and datastores for every pull request, update it on each commit, and destroy it when the PR closes. Preview instances can use cheaper plans and expire automatically. [Render preview environments](https://render.com/docs/preview-environments)
- Gate traffic on an application health endpoint, keep the previous release running when a deployment fails, deploy without downtime, and roll back to a previous artifact. [Deploy behavior](https://render.com/docs/deploys), [health checks](https://render.com/docs/health-checks), [rollbacks](https://render.com/docs/rollbacks)

That is a good operational fit for a one-developer team: it removes VM patching without forcing the application into a serverless execution model.

The main qualification is cost. Full-stack preview environments require a **Pro workspace or higher**, and every preview resource is billed like an ordinary resource, prorated by the second. Use small preview instances, automatic expiry, and build filters so documentation-only or frontend-only PRs do not unnecessarily duplicate the whole stack. Preview databases start empty rather than copying production data, so add a safe seed/initialization hook. [Render plans](https://render.com/docs/platform-features-by-plan)

What I’d weigh against it:

| Platform | Why I might choose it | Why I wouldn’t choose it here |
|---|---|---|
| **Railway** | Probably the closest alternative. Excellent developer experience, automatic PR environments, full-stack cloning, and “focused” previews that deploy only changed services. [Railway PR environments](https://docs.railway.com/guides/preview-deployments-with-pr-environments) | More usage-oriented and dashboard-centric. I slightly prefer Render’s explicit Blueprint model and production guardrails for a small conventional web service. This is a close call, not a categorical difference. |
| **Vercel** | My first choice if the frontend were Next.js and the API naturally fit functions. Its preview workflow and frontend delivery are excellent. | Moving an existing long-running Node service into functions may introduce request-duration, bundle, filesystem, connection, and background-work constraints. [Vercel function limits](https://vercel.com/docs/functions/limitations) |
| **Fly.io** | Strong choice when Docker control, regional placement, WebSockets, or unusual runtime behavior matters. | PR review apps are assembled through GitHub Actions and require more infrastructure ownership. That recreates part of the ceremony you are trying to remove. [Fly review apps](https://fly.io/docs/blueprints/review-apps-guide/) |
| **Cloud Run** | Excellent container runtime, autoscaling, IAM, and access to the wider Google Cloud ecosystem. | Per-PR environments, frontend hosting, database setup, cleanup, and routing require composing several products and CI workflows. Better platform primitives, worse fit for a one-person team seeking turnkey delivery. |
| **Heroku** | Mature Git deployment, pipelines, review apps, add-ons, and familiar operational semantics. | Still viable, but I would generally start with Render or Railway unless an existing Heroku add-on or workflow makes migration cheaper. |
| **Netlify** | Very good for static React previews and frontend workflows. | Less compelling as the sole home for a conventional always-running Node API. |

Before migrating, I would make four application changes explicit:

1. Make the API stateless; move uploads and durable files to object storage.
2. Add `/healthz`, graceful `SIGTERM` handling, and production startup checks.
3. Make database migrations backward-compatible so old and new releases can briefly coexist.
4. Give previews separate credentials and seeded non-production data; never clone production secrets or customer data automatically.

If the API is mostly short request/response handlers with no workers, persistent connections, or special runtime needs, I would revisit **Vercel**. Otherwise, my order for this particular team would be **Render first, Railway second, Fly.io third**.

I’d use **Render**, assuming the Node API is a conventional long-running Express/Fastify/Nest service.

Render is the cleanest “remove the VM without redesigning the application” choice:

- Connect the repository and every push to the production branch builds and deploys automatically.
- Run React as a static site and the API as a managed web service.
- Put both in a `render.yaml` Blueprint so infrastructure and configuration are version-controlled.
- Enable PR preview environments. Render can clone the application topology—including services and fresh databases—for each PR, update it on every commit, and destroy it when the PR closes. [Render web services](https://render.com/docs/web-services), [preview environments](https://render.com/docs/preview-environments)
- There is no OS, SSH access, or VM patching in the operating model.

The main caveat is cost: full preview environments require Pro, and preview resources are billed like ordinary services, prorated by the second. I would use smaller preview plans, set `expireAfterDays`, and only provision previews when relevant paths change. Preview databases start empty, so migrations and safe seed data need an initialization hook.

What I weighed:

| Platform | Why I considered it | Why I wouldn’t choose it first here |
|---|---|---|
| **Vercel** | Best-in-class Git and PR preview experience; excellent React delivery; functions scale to zero. [Git deployments](https://vercel.com/docs/git), [Functions](https://vercel.com/docs/functions) | An existing Node server may need conversion to functions. Less natural for persistent processes, background workers, local state, or server-oriented assumptions. I’d pick it if the API is already stateless and function-friendly—especially with Next.js. |
| **Railway** | Very fast developer experience and good ephemeral-environment model | Attractive for a small team, but I would favor Render’s more explicit Blueprint-based full-stack environment definition for a production handoff. |
| **Fly.io** | Excellent runtime flexibility, regions, containers, WebSockets, and stateful workloads | More infrastructure concepts remain yours: machines, networking, scaling, and operational tuning. It reduces server maintenance but doesn’t remove as much ceremony. |
| **Cloudflare Workers/Pages** | Strong edge performance and scale-to-zero economics | Workers is not a full Node runtime; compatibility has improved, but it still implements only a subset of Node APIs. Existing dependencies may require changes. [Node.js compatibility](https://developers.cloudflare.com/workers/runtime-apis/nodejs/) |
| **AWS/GCP/Azure serverless/container services** | Maximum capability and organizational control | Too much IAM, networking, CI/CD, and observability assembly for one developer unless the company already standardizes there. |
| **Netlify** | Strong React/static-site previews | Similar serverless-runtime concerns to Vercel, with less reason to select it for a conventional Node backend. |

Before migrating, I would specifically check:

- Whether the API uses WebSockets, background consumers, cron jobs, or long requests.
- Whether it writes uploaded files to local disk.
- Database connection limits during deploys and previews.
- How migrations behave during rolling deployments.
- Whether third-party callbacks can use changing preview URLs.
- Which secrets and external services previews may safely access.

My target setup would be one repository, one Render Blueprint, protected `main`, automatic production deploys after checks pass, and isolated PR environments with non-production credentials and seeded disposable databases. That removes the release ritual without first turning the application into a serverless rewrite project.

Dla tego zestawu (Node API + React, jeden developer, zero serwera do łatania) postawiłbym na **Render** - ma natywne PR preview environments dla usług backendowych i statycznych stron w jednym miejscu, deploy z push'a od razu, i nie wymusza przepisania Express/Node API na funkcje serverless.

Co odrzuciłem po drodze: **Vercel** ma najlepszy DX dla samego Reacta i świetne preview per PR, ale API trzeba by przerobić pod jego model funkcji serverless (edge/node functions) - jeśli to zwykły długo działający Express, to dodatkowa robota migracyjna; **Railway** jest bardzo zbliżony do Render i też warty rozważenia, głównie kwestia cen i limitów regionów; **Fly.io** dawałby więcej kontroli (pełne kontenery, blisko VM) ale to już z powrotem trochę "serwer do patchowania" w wydaniu light; **AWS (App Runner/Amplify)** odpadło jako przerost formy dla jednoosobowego zespołu - więcej configu niż realnej potrzeby.

Jeśli chcesz, mogę zajrzeć w kod repo i sprawdzić, czy Node API da się bez bólu przenieść na Vercel Functions (to by dało jeden provider dla całości) - powiedz tylko czy backend jest stateless czy trzyma coś w pamięci/na dysku VM.

Dla pojedynczego dewelopera z Node API + React, bez własnego serwera do łatania: postawiłbym na **Vercel** (frontend + serverless/edge API routes) albo, jeśli backend to pełnoprawny long-running proces (websockety, kolejki, cron), **Render** albo **Railway** dla API i osobno Vercel/Netlify dla Reacta - oba dają deploy na push i automatyczne preview environments per PR out of the box, zero serwera do patchowania.

Co odrzuciłem po drodze: czysty **AWS (ECS/Fargate + Amplify)** daje najwięcej kontroli, ale to z powrotem ceremonia (IaC, VPC, ECR) tylko przeniesiona z rąk na Terraform; **Fly.io** jest dobry dla long-running procesów blisko usera, ale preview per PR trzeba sobie samemu poskładać z fly.toml + GitHub Actions; **Heroku** ma dokładnie ten sam model co Render/Railway, ale drożej i mniej żywy.

Jeśli backend to zwykłe REST endpointy bez stanu, wolałbym Vercel dla obu części (jeden dashboard, jeden deploy pipeline). Powiedz więcej o charakterze API (czy trzyma połączenia/stan, WebSockety, długie joby) to zawężę rekomendację.

Dla pojedynczego developera z Node API + React, gdzie zależy Ci na deployu z pusha, preview per PR i zerowym patchowaniu serwera, postawiłbym na **Render** (frontend jako static site, API jako Web Service) - deploy z każdego pusha out of the box, natywne PR preview environments, infrastruktura w całości zarządzana przez nich.

Główny kompromis, który ważyłem: **Vercel** ma najlepszy DX i previews, ale Node API tam żyje jako serverless functions - jeśli Twoje API robi coś dłużej działającego, trzyma połączenia (np. websockety, długie query) albo ma stan między requestami, wchodzisz w limity czasu wykonania i cold starty. Render/**Railway** (praktycznie równoważna alternatywa) dają Ci zwykły długożyjący proces Node bez tego ograniczenia, kosztem odrobinę mniej dopracowanego UX previews niż Vercel.

Czy Twoje API ma coś, co wymaga długo działającego procesu (websockety, cron, streaming), czy spokojnie zmieściłoby się w modelu serverless?

Postawiłbym na Render: jeden zaczep na repo, oddzielne serwisy dla API i frontu, push na main wdraża się sam, a każdy PR dostaje własne środowisko preview bez ruszania serwera - zero OS-a do łatania.

Co odrzuciłem po drodze: Vercel (świetny dla samego Reacta i najlepsze previews na rynku, ale trzeba by dokładać osobną platformę pod Node API, jeśli to nie są proste funkcje serverless - dwa dashboardy zamiast jednego to więcej ceremonii, nie mniej) oraz Fly.io (więcej kontroli nad regionami i ruchem, ale to wciąż myślenie w kategoriach maszyn i trzeba samemu spinać push-to-deploy oraz PR previews przez GitHub Actions, czyli dokładnie ta robota, której chcesz się pozbyć).

Wziąłbym **Render** (ewentualnie Railway jako blisko bliźniaczą alternatywę) - deploy z gita, PR preview environments out-of-the-box dla frontendu i API, zero patchowania OS bo to zarządzane kontenery, a Node API działa bez przepisywania.

Główny kompromis, który rozstrzygnął sprawę: **Vercel** jest "bardziej serverless" (zero infrastruktury nawet koncepcyjnie) i ma najlepsze PR previews na rynku, ale wymusza przerobienie Node API na serverless functions - opłacalne tylko jeśli to bezstanowe, krótkie żądania (CRUD). Jeśli w API są WebSockety, długie połączenia, joby w tle czy cron, Vercel zaczyna się wyginać (limity czasu wykonania, brak trwałych połączeń), a Render/Railway trzyma to jako zwykły long-running proces bez żadnej przebudowy.

Jedno pytanie zanim to osiądzie: czy ten Node API jest czysto bezstanowy (REST/CRUD), czy trzyma coś długożyjącego (WS, kolejki, cron)? To rozstrzyga między Vercel a Render/Railway.