We are rebuilding the web presence of Machon Ramhal, a small Torah publishing institute in Jerusalem founded in 1986, replacing three separate legacy sites (Hebrew, French, English) that are the same installation cloned once per currency, with a single trilingual site — Hebrew at the root, /en and /fr prefixed — serving one catalogue of about 100 books. It is built as one Next.js 16 application with Payload 3 embedded as the CMS and admin on PostgreSQL, deliberately self-owned rather than on a hosted store platform, because the institute must not be locked to a vendor. The only person who will operate it is the founder's son, who is not technical and works in Hebrew, and no developer will maintain it after handover, so the code has to be readable by a stranger and nothing may depend on someone remembering an undocumented ritual. with budget we trying to start free for the POC, took Neon (free) github, and thinking of the others tools ... The storefront, catalogue, cart, shipping rules, orders and a mock checkout are built and tested; what remains is a real payment provider (PayPal first, an Israeli card gateway second, hosted payment page only), deployment... where should we deploy?

The sharpest fork in the panel is Vercel-vs-not, and I just confirmed the fact that tips it: Vercel's Hobby plan Terms of Service explicitly say Hobby is restricted to "non-commercial, personal use only" and "all commercial usage of the platform requires either a Pro or Enterprise plan." That's not a performance nitpick — GPT and Gemini already flagged this, and they're right — it means the free-POC path several answers implicitly assume (Vercel Hobby → later upgrade) isn't actually available once this is a bookstore taking real payments, even during testing. That reinforces, not just repeats, my original call: Vercel's problem isn't only cold starts on the admin panel, it's that the free tier is contractually off-limits for exactly what this site is.

Where I'll push back is Gemini's fix — swap to Netlify to dodge the ToS issue. That solves the commercial-use problem but not the architecture problem: Netlify runs Next.js through its own serverless/edge functions, so you still get the ephemeral-disk-and-cold-start situation I warned about for Payload's image processing and any background jobs — you're not escaping the pattern, just renaming it. And Netlify's own free-tier terms say service "may be terminated... without cause, immediately upon notice," which is a bad foundation for a site that will hold PayPal/Israeli-gateway credentials and order history, POC or not.

Grok's addition — Hetzner + Coolify as a year-two move — is the one point that actually changes my thinking at the margin. Coolify does remove the raw-SSH ritual I was worried about for a VPS. But it doesn't remove the OS patching, Docker-daemon upgrades, and disk/backup monitoring underneath Coolify itself — someone still has to notice when the box needs attention, and "no developer will maintain it after handover" means nobody will. So I'd file that as a legitimate future option once the institute has even occasional paid ops help, not a launch recommendation.

Net: Railway (Render as the free-tier fallback), one long-running Docker container, Neon as-is, Cloudflare R2 for uploads — unchanged from round 0, now with a firmer reason to rule out Vercel/Netlify specifically: it's a commercial storefront from day one, and neither platform's free tier is built for that, on top of the serverless/persistent-process mismatch.

Deploy the application as a persistent container on Railway ($5–$10/mo), keeping Neon for PostgreSQL and Cloudflare R2 for book media.

Claude and Grok rightly identified a critical operational flaw in using serverless hosts like Netlify or Vercel for this stack: Payload 3 embedded in Next.js 16 is heavy. Running it as serverless functions creates 3–5 second cold starts in the admin dashboard and risks function timeouts during sharp image processing when uploading book covers. For the founder's son, those admin lags will feel like a broken website.

Railway solves this by running Next.js in standalone mode as a managed continuous Node process. It deploys automatically on every git push to GitHub, requires zero server administration, and avoids cold starts completely.

However, Grok’s suggestion to eventually migrate to Hetzner with Coolify must be firmly rejected. A self-managed VPS forces a non-technical operator to handle OS updates, Docker container crashes, and SSL renewals—the exact operational nightmare this project must avoid.

Stick to this bulletproof, zero-ops trilogy:

1. Compute: Railway (app + CMS in one container via Next.js standalone build).
2. Database: Neon (Postgres, managed connection pooling).
3. Media: Cloudflare R2 (S3-compatible, zero egress fees for book cover images).

This setup costs around $5/month, eliminates cold starts for the non-technical maintainer, and requires no developer intervention after handover.

The persistent-process concern does not outweigh Vercel’s operational simplicity: use Vercel for the POC, then keep it for production on a paid plan if the tests are clean. Payload 3 can run there; the real requirements are external object storage (R2/S3), idempotent webhooks, and avoiding filesystem-based uploads—not a permanently running Node process.

The important correction is commercial use: do not assume Vercel’s free Hobby plan is suitable once the site accepts real orders. For a genuinely free, noncommercial POC, use Vercel + Neon Free; for live sales, budget for Vercel and paid/appropriate Neon, or use Railway/Render as the fallback if a persistent container proves materially more reliable for Payload admin and scheduled work. Railway’s trial credits are not a durable free production plan, and Render’s free service sleeps, so neither is a sound “set it and forget it” live deployment.

Whichever host you choose, deploy from GitHub, use R2/S3 from day one, keep Neon as a separately replaceable PostgreSQL service, and test admin uploads, PayPal callbacks, Israeli-gateway callbacks, email, and rollback before handover.

I'll verify a few contested claims (Vercel Hobby commercial rules, Railway/Render free tiers, Payload + serverless realities) before sharpening the recommendation against the panel.Railway remains the right default — not because “self-owned” is a slogan, but because Payload’s admin is a daily tool for one non-technical operator, and serverless cold starts plus connection churn turn that into mystery latency and broken uploads. Vercel Hobby is also a hard no once real payments or book sales go live: its fair-use rules ban commercial use and any payment processing on the free tier.[1]

The panel split is exactly here. Serverless fans (Vercel / Netlify) win on pure push-to-deploy zero-ops for a static or lightly dynamic Next app. They lose for this stack: Payload initializes collections, pools DB connections, and runs admin/media work as a long-lived Node process. Cold starts of several seconds on /admin, ephemeral disks, and function timeouts are documented pain — not theoretical.[2] Keep-alive crons and S3 adapters paper over it; they add rituals the son should never own. Netlify Free does allow commercial use (unlike Vercel Hobby), but it is still serverless with hard credit caps that can pause the whole site — fine for a brochure POC, poor for cart, webhooks, and daily catalogue edits.[3]

Railway’s own Payload + Postgres guide matches the architecture: GitHub push → persistent container, env vars, custom domain, optional bucket. Trial/credits cover the POC; Hobby is a $5 floor with usage credit and is realistic early production for ~100 books. Keep Neon (pooler) for now; add Cloudflare R2 from day one for covers/PDFs so redeploys never eat media. Code stays portable with output: "standalone" — same artifact can later sit on another PaaS or a VPS.[4]

On the pure VPS path: the warning against raw Hetzner without a maintainer is correct. OS patches and Docker drift are exactly the undocumented rituals you forbade. Coolify only becomes worth it after the site is stable and you have a one-page runbook the son can follow; treat it as optional year-two ownership, not the launch plan. Do not split app hosting across sleeping free tiers (Render free) either — admin that sleeps overnight is the wrong UX for the operator.

Concrete launch stack: GitHub → Railway service (Dockerfile or Nixpacks), Neon DATABASE_URL + pooler, R2 via Payload’s S3 adapter, PayPal hosted checkout + idempotent webhooks, secrets only in the host dashboard. README at repo root: deploy, rollback, DB backup, secret rotate, “what red means in the logs.” That is stranger-readable and vendor-portable without locking the institute to a store platform.

Skip free Vercel for anything that sells books; skip sleeping free PaaS for the admin; skip unattended VPS until you actually need the last dollar of ownership. Railway gets you live, operable, and movable.

Stick with Railway for deployment, not Vercel, because the best operational fit here is a persistent container that keeps Payload’s admin, uploads, and migrations simple for a nontechnical operator. Railway’s own Payload guidance shows the clean path: GitHub deploy, DATABASE_URI, PAYLOAD_SECRET, NEXT_PUBLIC_SERVER_URL, and output: "standalone"—exactly the kind of low-ritual setup you need.[2][5]

For the POC, keep Neon Free if you want to stay at $0; Neon’s free tier is permanent and is enough for a small catalog site with light traffic.[6][7][12] If you want to avoid future churn, use Cloudflare R2 or another S3-compatible bucket for media from day one, because local disk on any app host is the part most likely to bite you later.[2][4][5]

So the practical answer is: deploy the app on Railway, keep Neon for the database in the free POC, and attach object storage for files; later, keep the same Railway setup and swap in paid DB/storage only if usage demands it.[2][5][6] That gives you the least brittle handover without forcing a VPS or a serverless setup onto a Hebrew-speaking, nontechnical sole operator.[1][2][5]

Use Vercel’s free tier for the POC, but deploy the live production store to Railway. GPT and Gemini correctly flagged that Vercel’s Hobby plan prohibits commercial use, making it a dead end for the live bookstore. Additionally, Claude and Grok are right that Payload 3’s admin panel suffers from serverless cold starts on Vercel, which will frustrate a non-technical daily operator. Railway runs a persistent Node container, keeping the CMS snappy and eliminating serverless edge-case debugging while still requiring zero server maintenance. Pair Railway with Neon and Cloudflare R2 for a simple, $5–$20/month production setup that keeps the code portable and the operator out of the infrastructure weeds.