Configuring Origins
On this page 5 sections
An origin connects a public application hostname to the backend server that runs it. Add and manage origins in the web console; the control plane distributes the configuration to the domain's nodes automatically.
Add an origin in the console
- Open Infrastructure and select Manage for the domain that will serve the application.
- Check the domain's Master assignment. This is the node that must be able to reach the application backend.
- Select Add origin.
- Enter the Origin hostname visitors will request, such as
app.example.com, and the Backend address that the master will connect to. - Review the switches and timeout described below, then select Add origin to save.
- Allow the configuration revision to reach the running nodes, then check Domain health and test the application through its public hostname.
You can also attach the first origin when creating a domain. Adding an origin defines QSCS routing; it does not create DNS records, install the application or issue the certificate for your public HTTPS listener. Your public hostname should resolve to the entry point serving that QSCS domain.
Backend addresses are relative to the master
The backend address is resolved and contacted from the elected master node, not from each thin node and not from the computer running your browser. Thin nodes use the master as their implicit upstream. You do not need to expose the application backend separately to every thin node.
127.0.0.1:8080means port 8080 on the master itself.10.0.0.5:8080means a private server reachable over the master's network.https://backend.example.comuses DNS and HTTPS connectivity from the master.
If a fallback is promoted, it becomes the master and must be able to use the same configured backend address. A loopback address then refers to the promoted node itself. QSCS replication does not install or replicate the backend application. See Choosing the Master for fallback election.
Use the application's actual backend address. An address that routes back through the same public QSCS entry point can create a forwarding loop.
Supported address formats
| Example | Connection from the master |
|---|---|
127.0.0.1:8080 | HTTP to the given IP address and port. |
backend.example.com:8080 | HTTP to the hostname and explicit port. |
http://backend.example.com | HTTP, using port 80 by default. |
https://backend.example.com | HTTPS, using port 443 by default. |
https://backend.example.com:8443 | HTTPS on an explicit port. |
https://[2001:db8::10]:8443 | HTTPS to a bracketed IPv6 address and explicit port. Bare IPv6 endpoints also use brackets, for example [::1]:8080. |
A hostname or IP without a port defaults to HTTP on port 80. A bare address such as backend.example.com:443 still uses HTTP: use https:// to select TLS. Enter a backend authority only, without a path, query string, fragment or embedded username and password. A trailing slash on an HTTP or HTTPS address is accepted and removed when saved.
QSCS preserves the incoming request path and public Host header. For HTTPS, the backend hostname supplies TLS SNI and certificate verification. The backend must therefore accept the application's public hostname at the HTTP layer, even when its TLS hostname is different.
HTTPS verifies the backend certificate against the node's trusted certificate authorities and the hostname or IP in the backend address. For a private CA, install that CA in the trust stores of the master and any node that may replace it. Health probes use the same verified transport. A certificate failure does not fall back to HTTP.
Every origin setting
These are the defaults shown when adding an origin. Editing an existing origin shows its saved values.
| Setting | New-origin default | What it controls |
|---|---|---|
| Origin hostname | Required | The public application hostname, such as app.example.com. Enter it without a scheme, port or path. Register aliases such as www.example.com as separate origins. The hostname is read-only when editing; add a new origin to use a different hostname. |
| Backend address | 127.0.0.1:80 | The application endpoint reached from the master. Use one of the formats above. This can be changed later without changing the public origin hostname. |
| Proxy every request | On | Fetch requests from the backend during normal operation instead of satisfying them from the shared response cache. Turn it off to allow eligible cached responses. Keeping it on does not disable eligible browser delta responses: fetching from the application and reducing bytes sent to the browser are separate decisions. |
| Require a signed identity | Off | Require a valid authenticated QSCS identity before protected application requests can reach this origin. This enables the identity gate; it does not create your application's login flow. Integrate authentication using Configuring Gated Identity before enabling it for users. |
| Browser delta navigation | On | Automatically delivers the browser runtime to eligible HTML pages and enables supported document navigation deltas. Turn it off if a site's navigation is incompatible. This switch controls browser navigation, not peer synchronisation or API identity policy. See Browser Substrate & WASM Bootstrap. |
| Persist cache | Off | Retain cached responses across daemon restarts and use master-managed shared cache updates for eligible anonymous content. Enable it only where anonymous responses are suitable for shared delivery: it is an explicit caching policy, including for eligible responses without a positive origin cache lifetime. Credentialed responses remain separate. It does not override Proxy every request; turn that switch off when you want normal requests served from eligible cached responses. |
| Headless timeout (seconds) | Blank: daemon default | The per-origin upstream connection and I/O timeout used when contacting the backend. Enter a whole number from 1 to 600, or leave it blank to use daemon defaults. A longer value gives slow backends more time but can keep requests waiting longer. This is not a cache lifetime, the duration of headless service or a timer for promoting a fallback node. |
Shared response caching, browser delta delivery and identity enforcement serve different purposes. For a public application whose responses are safe to cache, turn off Proxy every request to allow eligible cache hits. For an application that must be contacted on each request, keep it on; compatible browser navigation can still benefit from deltas. Configure identity and federated API caching separately where your application requires them.
Save and check changes
In the domain's Origins list, select Edit settings, change the required fields and select Save settings. Saving advances the domain's configuration revision. Running nodes receive the new snapshot automatically, normally on their next configuration poll, and restart when required to apply it. Routine changes do not require editing qscs.conf or manually re-subscribing every node.
Check Domain health after the revision has applied. If an origin needs attention, follow its health link to the affected item. Confirm the backend address is reachable from the current master, that the application accepts the public hostname and, for HTTPS, that its certificate is trusted and matches the configured backend address.
Use Remove beside an origin to remove its routing entry from this domain. This does not delete the backend application or its DNS records. For background on the routing model, see Origins & the Implicit-Origin Model.