Project Configuration

Every project carries a small set of platform settings—the knobs that control how it's served. The config command views and changes them.

Viewing configuration

surge config example.com

Prints the project's current settings as key: value pairs. A fresh project has nothing set and prints Empty.

Changing configuration

Pass any setting as a flag:

surge config example.com --<setting> <value>

The change is applied immediately—no redeploy required—and the command prints the resulting configuration so you can confirm what's now in effect.

Configuration from your project files

Most day-to-day behavior isn't set through config at all—it's driven by files in the directory you publish, which travel with every deploy:

File	Controls
`CNAME`	The project's domain. See Publishing.
`.surgeignore`	Files excluded from deploys. See Publishing.
`AUTH`	Password protection (HTTP basic auth). See the platform docs.
`CORS`	Cross-origin resource sharing. See CORS.
`ROUTER`	Redirects and routing rules. See Redirects.
`200.html`	Client-side routing for single-page apps. See SPA routing.
`404.html`	The not-found page. See Custom 404 pages.

This split is deliberate: anything that should be versioned with your code lives in the project; anything about the running service—like which revision is live, or HTTPS enforcement via a protocol-prefixed publish—is platform state.