Settings Page
The settings page holds application-wide configuration. The sidebar entry and the page are available to administrators. A secondary sidebar jumps between sections.
Some sections differ between self-hosted and cloud deployments. On cloud, the Cache configuration and SMTP sections are hidden.
Recommendation servers
Section titled āRecommendation serversāManage the list of recommendation server URLs the application queries. Add or remove server entries.
By default, the official Trailer.dev recommendation catalog https://catalog.trailer.dev is added as a server.
For more on recommendations read more on the Recommendations page.
Cache configuration
Section titled āCache configurationāSelf-hosted only. Set the Cache directory used by the application. This is the directory where Trailer stores certain items, such as the list of available PyPI packages. By default, it takes the XDG Cache Home directory set on the system, when the server is first launched.
Forward auth
Section titled āForward authāConfigure cookies used by forward authentication that protects workspace URLs. When enabled you can set:
- Auth cookie: name and lifetime in seconds.
- CSRF cookie: name and lifetime in seconds.
- Insecure cookies: a toggle that indicates whether to store the Auth and CSRF cookies as insecure. You may need to set this to disabled if youāre using the Trailer.dev server with a
http://, non-localhost domain.
SSO settings
Section titled āSSO settingsāConfigure single sign-on providers shown on the login page:
- GitLab
- Microsoft
- GitHub
- Generic OpenID Connect (OIDC)
This section also configures the mapped fields used when importing user details from a provider.
SMTP settings
Section titled āSMTP settingsāSelf-hosted only. Configure outbound email used for password resets, email changes, and invitations.
- Sender name and sender address.
- Use SMTP mail server toggle. The connection fields below are enabled only when this is on.
- Host, port, username, password.
- More options: TLS encryption (Auto / StartTLS or Always), authentication method (PLAIN or LOGIN), and an EHLO domain (defaults to localhost).
Updates
Section titled āUpdatesāShows the current version. On self-hosted deployments it also shows the latest version, indicates when an update is available, and lets you pick a version tag and trigger an update. On official, cloud hosted instances only the current version is shown.
Triggering an update downloads the selected release, verifies its checksum and cryptographic signature, replaces the server executable, and restarts the server. Expect a brief moment of downtime while it comes back up. If the download fails verification, or the swap fails, the previous version is restored and the server keeps running.
Good to know:
- Fetching the version list and the release files requires the server to have outbound internet access.
- Linux: the whole update happens in place. The running server is replaced by the new version without starting a new process, so it stays under the control of whatever supervises it (for example a system service).
- Windows: an in-place restart is not supported by the OS. The new version is started as a separate process and the old one exits. If you run Trailer as a managed Windows service, the service manager can lose track of the new process, so verify the server came back after updating and restart the service manually if it did not.
- If you run the server from a container image, an in-place update only modifies the running container. Recreating the container reverts to the imageās version, so update by switching to a newer image instead.
- The version picker also lists older releases, so downgrading is possible. Newer versions may upgrade the database in ways an older version does not understand. Make a backup before downgrading.