Vercel and Render

Two days before I started writing this chapter, Vercel got hacked.

Not a theoretical vulnerability. A real breach, traced to an AI office-suite tool called Context.ai that got compromised by malware. The malware gave attackers a pivot into a Vercel employee’s Google Workspace, which gave them access to internal Vercel systems, which gave them access to customer environment variables. API keys. Database credentials. Payment tokens. The stuff you put in those little text boxes in your deployment dashboard and assume is safe.

I’m leading with this because it shapes how I want you to think about deployment platforms. Not as magic boxes that make your code go live. As infrastructure you depend on — with real security implications, real cost structures, and real tradeoffs.

What deployment platforms do

In the old days, “deploying” meant SSHing into a server, pulling code, restarting a service, and hoping the SSL certificate wasn’t expired. Modern platforms collapse all of this into one workflow: push code to GitHub, get a live URL. The platform handles building, hosting, SSL, CDN, scaling, and rollbacks. You connect a repo, merge a pull request, and your changes are live — with a preview URL for every branch.

Vercel and Render both follow this pattern. The difference is what they’re optimized for.

Vercel: the frontend cloud

Vercel is built around serverless and edge computing, made by the same company that makes Next.js. You push code, Vercel builds it, distributes it globally across their CDN, and serves it fast. Static pages load from the edge. Dynamic pages render in serverless functions that spin up on demand.

Preview deployments are the killer feature. Every pull request gets its own live URL. Your designer checks the UI. Your PM tests the flow. Your client sees the changes. All before production. For client work, this is invaluable. Instead of scheduling a demo, you send a link. I’ve saved at least a dozen meetings by sending a preview URL with a two-line message. Half the time they approve in the same thread.

Vercel excels at Next.js applications, static sites, serverless API routes, edge functions, and AI applications (Fluid Compute charges only for active CPU time, so LLM I/O waits don’t inflate bills). What it can’t do: long-running processes (functions time out at 60-300 seconds), background workers, persistent WebSocket connections, Docker containers, or anything stateful.

Pricing: Hobby is free but explicitly prohibits commercial use. Pro is $20/seat/month with a usage credit. Watch bandwidth overages at $0.15/GB.

The breach lesson: Mark every environment variable as “sensitive” when creating it. Sensitive variables are encrypted at rest and can’t be re-read from the dashboard. The non-sensitive ones were exactly what the attackers accessed. The attack chain ran through a compromised third-party AI tool → a Vercel employee’s Google Workspace OAuth grant → internal systems → customer environment variables. Every OAuth grant you’ve approved is an attack surface.

Render: the full-stack cloud

Render is what Heroku should have become. Where Vercel runs code in short-lived serverless functions, Render runs code in long-lived containers that stay running. This matters for everything Vercel can’t do.

Web Services — HTTP servers in any language, or any Docker image. PostgreSQL — managed databases with point-in-time recovery and read replicas. Background Workers — long-running processes for queues and data processing. Cron Jobs — scheduled tasks billed per second. Private Services — internal microservices not publicly exposed. Key Value — Redis-compatible in-memory store. Preview Environments — full stack replicas including your database, created automatically for each PR.

Blueprints are Render’s infrastructure-as-code: a single YAML file defining your entire stack (web server, worker, cron job, database, Redis) that Render provisions automatically when you push. Everything connected over a private network with auto-populated connection strings.

Pricing: Free tier is real but has teeth — services cold-start in 30-60 seconds after inactivity, databases auto-delete after 30 days. One of our engineers demoed a client prototype on the free tier. The client hit the cold start, waited forty-five seconds, and asked “is it always this slow?” Seven dollars a month would have prevented it. Professional is $19/user/month. Compute starts at $7/month per service.

The decision framework

Not “which is better.” Which shape matches your application.

Use Vercel when you’re building a Next.js app, your backend is serverless API routes, you need global edge performance, or your compute is bursty and short-lived.

Use Render when you need a real database alongside your app, have background workers or queues, need Docker, have long-running processes, want persistent WebSocket connections, or want preview environments that include your database.

Use both when your frontend is Next.js (Vercel) and your backend is a separate API with a database (Render). This is the setup we use for most client projects. Vercel handles serving the UI fast. Render handles running the API and database. Neither is doing a job it wasn’t designed for.

Use neither when you need bare metal, specific geographic regions they don’t cover, or you’re at a scale where managed pricing doesn’t work. Look at Fly.io, Cloudflare Workers, or direct cloud providers.

The alternatives

Netlify — Vercel’s closest competitor. Free tier allows commercial use (unlike Vercel). Good choice if you want the same workflow without the free-tier restriction.

Cloudflare Pages + Workers — Zero egress fees. $5/month flat with 10 million requests. Best for cost-sensitive edge projects. The tradeoff is lock-in to Cloudflare APIs.

Railway — Render’s closest competitor. Usage-based pricing with scale-to-zero. Beautiful UI. No free tier ($5/month minimum).

Fly.io — Globally distributed Firecracker microVMs. Best for real-time apps and specific geographic requirements. More operational complexity than Render.

Security hygiene

The Vercel breach isn’t unique. LiteLLM, Axios npm, Codecov, CircleCI, Snowflake — supply chain attacks on managed platforms are the new normal.

Treat every environment variable as a credential. Rotate credentials quarterly, not just after breaches. Review your OAuth grants right now — revoke anything you don’t actively use. I did this after the breach and found eleven apps I’d forgotten, including two I didn’t recognize. Use per-environment secrets (staging Stripe key ≠ production Stripe key). Monitor every third-party tool your team uses — each one is a potential entry point.

The bottom line

Deployment is a solved problem in 2026. Push to GitHub, get a live URL. The hard part is making the right architectural choice, managing credentials responsibly, understanding your cost structure, and having a plan for when things go wrong.

“Managed” doesn’t mean “safe.” It means you’ve outsourced operations to someone else’s security posture, their vendors, and their employees’ OAuth grants. The platform you choose matters less than the discipline you bring to using it.

This is the free web edition of Chapter 10. The full text — with deployment configurations, render.yaml blueprints, GitHub Actions integration scripts, breach response checklists, and cost comparison tables — is available in 42: The AI Builder’s Stack, coming Q3 2026 on Amazon in hardcover, paperback, and digital.