Project Configuration

Every project carries a small set of platform settings—the knobs that control how the edge serves it. The config command views and changes them, and changes take effect across every edge node immediately: no republish, no cache to wait out.

Viewing configuration

surge example.com config

Prints the project's current settings as key: value pairs. A fresh project has nothing set and prints Empty—every setting below is optional, and absence means the sensible default. (Inside a project directory, plain surge config does the same.)

Changing configuration

Pass any setting as a flag; pass null to clear one back to its default:

surge example.com config --force https      # set
surge example.com config --force null       # clear

The command prints the resulting configuration so you can confirm exactly what's now in effect.

The settings

Setting	Values	What it controls
`force`	`http`, `https`	Redirect all traffic to one protocol. `https` is the right value for almost every project—publishing to `https://example.com` sets it for you.
`redirect`	a domain	Answer every request with a redirect to another domain—how a retired domain sends visitors to its successor.
`cors`	a domain, `*`	Allow cross-origin requests from one origin, or any. The `CORS` file does this per-project in code; the setting does it from the platform side.
`cache`	`strict`, `casual`	Tune the edge caching posture. The default Lucid Caching is right for almost everyone.
`hsts`	seconds	Send a `Strict-Transport-Security` header with the given max-age, telling browsers to insist on HTTPS.
`ttl`	seconds	Override the cache lifetime the edge advertises.

Settings that gate paid features (like cors) follow your plan.

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 publish:

File	Controls
`CNAME`	The project's domain. See Publishing.
`.surgeignore`	Files excluded from publishing. See Publishing.
`AUTH`	Password protection and protected paths. 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.

The split is deliberate: anything that should be versioned with your code lives in the project and rolls back with it, revision by revision. Anything about the running service—which revision is live, protocol enforcement, platform-side redirects—is config, applied to the domain no matter what's published there.