Configuration
Most Doors apps can start with the defaults.
Reach for configuration when you need to change a few app-level things:
- session or instance lifetime and runtime limits
- Content Security Policy
- esbuild behavior for scripts, modules, and stylesheets
- the server ID used in Doors runtime URLs and session cookie naming
- error pages, session tracking, ...
All of these are passed to doors.NewApp(...) as app options:
app := doors.NewApp(page,
doors.WithConf(doors.Conf{
RequestTimeout: 20 * time.Second,
InstanceTTL: 30 * time.Minute,
}),
doors.WithCSP(doors.CSP{
ConnectSources: []string{"https://api.example.com"},
}),
doors.ESProfile{
Minify: true,
JSX: doors.JSXReact(),
},
)
Options
Common app options are:
doors.WithConf(...)— runtime, session, and serving behaviordoors.WithCSP(...)— Content Security Policydoors.ESProfile{...}— simple esbuild profile settingsdoors.WithESProfiles(...)— esbuild profile selectiondoors.WithID(...)— server ID for runtime URLs and cookie namesdoors.WithSessionTracker(...)— observe session create/deletedoors.WithErrorPage(...)— custom error page
Doors fills in defaults automatically, so you usually set only the values you want to change.
Server ID
Use doors.WithID(...) when this app should have its own Doors runtime URL prefix and session cookie namespace.
If unset, the ID defaults to doors.
app := doors.NewApp(page, doors.WithID("blue"))
This value is used in two places:
- Doors runtime URLs are built under a prefix like
/~/blue/... - the Doors session cookie name becomes
blueby default
That separation is especially useful when you run multiple Doors deployments side by side, for example:
- sticky load-balancing setups
- blue/green or canary rollouts
- migrations where old and new deployments should not steal each other's Doors session
The ID must already be URL-safe. If it needs escaping, Doors will panic during setup.
System
Use doors.WithConf(...) for runtime and serving behavior. The value is doors.Conf.
doors.WithConf(doors.Conf{
SessionInstanceLimit: 6,
RequestTimeout: 20 * time.Second,
InstanceTTL: 30 * time.Minute,
})
The fields that matter most in practice are:
SessionInstanceLimit: max live page instances per session. Default12. If exceeded, older inactive instances are suspended.SessionTTL: how long the session lives after activity. If unset or too small, Doors raises it to at leastInstanceTTL.InstanceConnectTimeout: how long a new dynamic page can wait for its first client connection. DefaultRequestTimeout.InstanceTTL: how long an inactive instance is kept. Default40m, and never below2 * RequestTimeout.InstanceGoroutineLimit: max goroutines per page instance for runtime work. Default8.DisconnectHiddenTimer: how long hidden pages stay connected before disconnecting. DefaultInstanceTTL / 2.RequestTimeout: max duration of a client request or hook call. Default30s.ServerCacheControl: cache header for Doors-served JS and CSS resources. Defaultpublic, max-age=31536000, immutable.ServerDisableGzip: disables gzip for HTML, JS, and CSS.ServerSessionCookiePrefix: optional prefix for the internal Doors session cookie name. Empty by default, so withdoors.WithID("blue")the cookie is namedblue. Set it explicitly when you want browser-enforced cookie prefix rules such as__Host-or__Secure-.ServerSessionCookieNoSecure: omits theSecureattribute from the internal Doors session cookie. Use only for plain HTTP development.
The Solitaire* fields tune the sync transport between server and browser:
SolitaireSyncTimeoutlimits how long a pending server-to-client sync task may wait. If it is exceeded, the instance is ended.SolitaireQueueandSolitairePendingcontrol queue depth and backpressure.SolitairePing,SolitaireRollTimeout,SolitaireFlushSizeLimit, andSolitaireFlushTimeoutcontrol how the sync connection is kept alive and flushed.SolitaireDisableGzipdisables gzip for solitaire sync payloads without affecting HTML, JS, or CSS compression.
Most apps should leave the Solitaire* settings alone unless they are debugging runtime behavior or tuning under load.
CSP
CSP is off until you call doors.WithCSP(...).
doors.WithCSP(doors.CSP{
ConnectSources: []string{"https://api.example.com"},
ScriptStrictDynamic: true,
})
When enabled, Doors builds the Content-Security-Policy header per page and automatically collects hashes and sources from Doors-managed resources.
In practice, that means:
script-srcalways includes'self'plus collected script hashes and sourcesstyle-srcalways includes'self'plus collected style hashes and sourcesconnect-srcalways includes'self'
External script and style resources added through Doors also register their source automatically for CSP.
The field groups behave like this:
| Fields | nil |
[] |
values |
|---|---|---|---|
ScriptSources, StyleSources, ConnectSources |
keep only the Doors defaults | keep only the Doors defaults | append your values |
DefaultSources |
use the built-in default | omit the directive | emit your values |
FormActions, ObjectSources, FrameSources, FrameAcestors, BaseURIAllow |
default to 'none' |
omit the directive | emit your values |
ImgSources, FontSources, MediaSources, Sandbox, WorkerSources |
omit the directive | omit the directive | emit your values |
ReportTo only emits the report-to directive. You still need to send the matching Report-To response header yourself.
Esbuild
Doors already has a default esbuild profile. The base profile targets ES2022 and minifies output.
This is used for:
- the main Doors client bundle
- managed inline
<script>...</script>resources - buildable
<script src=(...)>resources - buildable
<link rel="stylesheet" href=(...)>and<style>...</style>resources
Use doors.ESProfile{...} for simple esbuild settings:
doors.ESProfile{
Minify: true,
JSX: doors.JSXReact(),
}
Use doors.WithESProfiles(...) when you need named profiles or full esbuild options. The argument is func(profile string) api.BuildOptions — return the esbuild options that should apply to that named profile.
The profile value comes from the profile attribute on script resources. Your function must support the default profile "", because Doors uses it for its own main client build too.
One important rule: resource types still apply the entry-point and output settings they require, so your esbuild options can be supplemented or overridden to make that resource type work.
Error Page
Use doors.WithErrorPage(...) to render your own page for internal runtime errors:
doors.WithErrorPage(func(r *http.Request, err error) gox.Elem {
return ErrorPage{Err: err}.Main()
})
The callback receives the original *http.Request and the runtime error.
Session Tracker
Use doors.WithSessionTracker(...) to observe Doors session create/delete events:
type tracker struct{}
func (tracker) Create(id string, r *http.Request) {
// e.g. seed a server-side store
}
func (tracker) Delete(id string) {
// e.g. clean up the server-side store
}
doors.WithSessionTracker(tracker{})
Create receives the new session ID and the request that triggered creation. The request must not be retained beyond the call, and its body must not be read.
Rules
- Start with defaults and change only the settings you actually need.
- Use
WithConffor lifetime, timeout, sync, and serving behavior. - Turn on CSP with
WithCSPwhen you want browser-enforced loading rules, then add only the extra sources your app really needs. - Use
ESProfilefor simple esbuild settings. - Use
WithESProfilesonly when one esbuild profile is not enough or the defaults don't fit.