Learn Remix - Deployment & Hosting

#Introduction

All your hard work ends at one moment: the application serving users in the real world. Episode 20 is the deployment map — how to choose a host, what happens during the build, and how to recover from mistakes safely.

The good news: Remix is designed to be deployable everywhere. Thanks to its adapter system, a single application codebase can run on a Node.js server, serverless platforms like Vercel and Netlify, edge platforms like Cloudflare Pages, or your own VMs. The main difference is how the server bundle is built and run, not how the application is written.

Episode 20 covers hosting options, server versus edge, build output and assets, and preview environments with rollbacks.

#Deployment Options for Remix

#Popular Platforms

Some of the most common deployment targets for Remix:

• Vercel: smooth Git integration, previews per commit, and a similar ecosystem to Next.js.
• Netlify: easy to use, serverless functions, and a built-in CDN.
• Cloudflare Pages: deployment to the edge network with very low latency.
• Fly.io: container VMs across regions worldwide for full control.

npm view @remix-run/vercel version
npm view @remix-run/netlify version
npm view @remix-run/cloudflare-pages version
npm view @remix-run/node version

Each platform uses its own adapter; choose one and adjust during scaffolding. Moving between platforms is still possible, but deciding early saves time.

Each platform also has a different pricing model — some are free for small projects and start charging as traffic grows. Study a platform's pricing model before committing, so you're not surprised at the end of the month.

#Criteria for Choosing a Host

Consider: runtime needs (full Node vs edge), user location, quota limits, and team comfort. Applications that need large file uploads or WebSocket are more comfortable on Fly.io; light content applications fit serverless platforms.

#Server versus Edge Deployment

#Node.js and VMs

Node.js-based deployment gives full access: filesystem, long-running processes, and native libraries. It suits complex applications that run continuously. This pattern is the most flexible because there are no runtime limits other than the ones you set yourself.

#Edge and Serverless

Serverless and edge run code per request, scale up and down automatically, and are often cheaper for sparse traffic. Their limits: no persistent filesystem, timeouts, and cold starts. The first cold start can be noticeable, but modern platforms have improved it a lot.

#A Practical Decision

Start with the platform most comfortable for a small project, and understand the trade-offs before scaling up. Adapter migration in Remix is usually isolated to entry.server and the config — the core application doesn't change.

For a learning project, one of the serverless platforms is the fastest starting point: Git integration, automatic HTTPS, and a clear dashboard. Once comfortable, try deploying to a second platform to understand the differences firsthand.

#Build Output and Asset Deployment

#What the Build Produces

The build command produces two groups of output:

build/            <- server bundle, dipakai server atau function
public/           <- aset statis: JS, CSS, gambar, di-cache CDN

Static assets in public are copied and can be cached aggressively; the server bundle runs as a server or function. Modern platforms handle this copying automatically from the adapter configuration.

Also understand how assets are served differently: the CDN serves static assets from the nearest location, while dynamic HTML pages are produced by the server or edge. Mixing a CDN for assets and a server for HTML is the most common Remix deployment pattern.

#Environment Variables in Production

Set secrets in the platform panel, not in code files. Each environment — production, staging, and preview — uses its own env values. Platforms usually provide env settings per project or per branch.

Don't forget to verify that secrets are actually read after deploying. A quick way to test: open a page that reads process.env and see whether the expected value appears. Wrong secrets are the classic cause of applications that work locally but break in production.

#Preview Environments and Rollbacks

#Previews for Every Commit

Modern platforms create a preview environment automatically for every pull request. Previews give you a clickable URL to test changes before merging. This closes the gap between code that passes CI and code that's actually used.

#Safe Rollbacks

When something goes wrong in production, a rollback is the emergency button. Platforms let you redeploy a previous version. The principle: a good deployment must always be reversible with one click. Keep a release history so rollbacks are quick and panic-free.

#Release Strategies

For big changes, combine previews and rollbacks with a staged release strategy. Feature flags or staged deploys give a smooth escape route when something goes wrong. Episode 23 covers modern release patterns further.

With all these elements — the right adapter, a split build, correct secrets, per-commit previews, and one-click rollbacks — deployment is no longer a stressful event, but a routine flow you can repeat calmly.

#Conclusion

Episode 20 completes the application's journey to production: choosing a host that fits your needs, understanding server versus edge, build output and asset deployment, and safe preview environments with rollbacks. Your application now truly lives in the real world.

The key takeaways:

• Adapters connect Remix to platforms: Vercel, Netlify, Cloudflare, Fly.io, and others.
• Node.js gives full access; edge and serverless give automatic scaling.
• The build produces a separate server bundle and static assets.
• Set secrets per environment in the platform panel.
• Preview environments for every pull request make review easier.
• Always make sure a rollback is possible with one click.

In the next episode, episode 21, we'll discuss edge and serverless — edge functions and serverless runtimes, deploying on Cloudflare Workers or Deno, runtime differences and environment considerations, and use cases for edge-first deployment. The host is chosen; now let's talk about the ends of the earth.