Learn Remix - Configuration & Environment

#Introduction

Up until episode 7, all your applications ran with default configuration. In production, that isn't enough: you need secrets, different envs per environment, adapter choices, and an optimized build. Episode 8 is the configuration layer.

The biggest change to hold onto: since Remix v3, all configuration lives in vite.config.ts. The remix.config.js file that often appears in old tutorials is no longer used. Vite serves as both the bundler and the dev server, so one configuration system handles everything.

Episode 8 covers vite.config.ts, environment variables, choosing adapters and runtimes, managing static assets, and build optimization.

#Build Configuration in vite.config.ts

#The New Configuration Center

All Remix options are configured through the remix() plugin inside Vite's defineConfig. Some important options you can set there:

import { vitePlugin as remix } from "@remix-run/dev";
import { defineConfig } from "vite";
import tsconfigPaths from "vite-tsconfig-paths";
 
export default defineConfig({
  plugins: [
    remix({
      future: { v3_fetcherPersist: true },
    }),
    tsconfigPaths(),
  ],
  build: { target: "node20" },
});

The future option on the remix plugin enables next-version behaviors gradually. With this pattern, major Remix upgrades don't have to happen all at once — new features are enabled one by one.

#Don't Store Secrets Here

Important context: this file gets compiled and can end up in the client bundle for code imported from it. Because of that, never write secrets directly in vite.config.ts. Secrets should only enter through environment variables read on the server.

#Environment Variables

#Separating Code from Configuration

Environment variables separate configuration from code: values change per environment, code doesn't. In Node.js, values are accessed via process.env. In Remix, the safe places to read them are loader, action, or modules that only run on the server.

Reading env vars in a loader

export async function loader() {
  const apiUrl = process.env.API_URL;
  const apiKey = process.env.API_KEY;
  return { apiUrl };
}

process.env.API_KEY is only available on the server — never send it to the client. If a value truly needs to be visible in the browser, give it a prefixed name, read it in the root loader, and share it through context.

#Local Env Management

Create a .env or .env.local file at the project root for local values. Modern hosting platforms support setting the same env values graphically or via CLI. Environment variables across environments: development, staging, and production must be carefully distinguished so staging secrets don't leak into production.

#Build Target, Adapter, and Runtime

#The Adapter Determines the Platform

The adapter is the bridge between Remix and the host server. Remix v3 ships with several built-in adapters: Node.js, Vercel, Netlify, Cloudflare, and Deno. The adapter choice determines how the server bundle is built and run.

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

Choose the adapter based on your deployment platform; each adapter adjusts entry.server and the build output. It's fine to switch adapters later, but better to decide from the start.

#Server Runtime versus Edge

The adapter also determines the runtime: full Node.js, or the lightweight, fast edge. Different runtimes have different API support — for example, filesystem access doesn't exist on the edge. These comparisons are covered in depth in episode 21.

#Managing Assets in public and Imports

#The public Folder

All files in the public folder are copied as-is to the build output. Put files that don't need bundler processing here: favicon, robots.txt, manifest, and static images. Files in public are accessed directly from the root, e.g. public/logo.svg becomes /logo.svg.

#Importing Assets Through the Bundler

For assets you want the bundler to optimize — hashing file names, compression, or inlining — import them directly in code. Vite handles common asset types like images, CSS, and fonts. The result is hashed file names so caching can be very aggressive.

#Build Optimization

#Production Build

Run a build to see the optimization results:

npm run build
npm run start

The build produces a build folder with a server bundle and static assets ready to deploy. Watch the bundle size in the logs — a large number early on can be a sign of unnecessary imports.

#Bundle Reduction

Remix's main optimization comes from structure: each route carries its own code, and large static imports can be made lazy. Avoid importing big libraries in the root layout if only one route uses them. Code-splitting and tree shaking practices are deepened in episode 19.

#Conclusion

Episode 8 gives you control over configuration: vite.config.ts as the build center, environment variables to separate code from configuration, adapters and runtimes for the deployment platform, the public folder for static assets, and optimized build practices.

The key takeaways:

• All Remix v3 configuration lives in vite.config.ts; remix.config.js is no longer used.
• Don't store secrets in code or configuration; use environment variables.
• process.env is read in loaders and actions, never sent directly to the client.
• The adapter determines the platform: Node, Vercel, Netlify, Cloudflare, or Deno.
• The public folder is copied as-is; other assets are imported through the bundler.
• A production build creates a deploy-ready bundle worth auditing for size.

In the next episode, episode 9, we'll discuss caching and performance — cache headers and cache control, data revalidation with stale-while-revalidate, image optimization, and performance monitoring with Lighthouse. Configuration is tidy; now it's time to make your application feel fast.