Settings reference

Settings reference

Every page under Admin, Settings: what it decides, what you need before you fill it in, and where to get it.

How settings work

Every setting lives in the portal, under Admin, Settings, one page per group. The setup wizard asks the few you need on day one; the rest can wait until you need them. A change takes effect on the next request. A setting that starts a schedule says so on the field: it applies after the next restart.

Keys, passwords and private keys are stored encrypted and are never shown again. The box stays empty even when one is stored: leave it empty to keep the stored value, type a new one to replace it.

An administrator can also ask Ask cyantula in the portal to read or change a setting, and a coding agent connected over MCP can do the same for an admin. Either way the change is checked like a save on the Settings page, and secrets are never read back.

Settings you only need when something is wrong are folded away under Advanced. Every field has a sentence of help in the portal. The pages below explain the ones where you need something from somewhere else first, like an API key or a DNS record.

Every settings page

The settings pages in the portal and what each one decides
PageWhat it decides
AddressesThe domain colleagues open, the domain apps get a name under, and whether HTTPS ends at Cloudflare or on this server.
Sign-in and accessInternal accounts and their password rules, who the administrators are, how long a sign-in lasts, external share links, and whether sensitive apps may be opened to outsiders by their owner.
Code and repositoriesThe GitHub App that clones repositories, opens changes as pull requests and creates repositories for new apps.
AIWhich model each AI feature uses, and the model published apps get when they ask the platform for AI.
AI providersThe model providers the platform may call: hosted ones with an API key, and your own Ollama or vLLM server.
What the AI may doThe chat in the portal, the coding agent, and the loops that repair a crashed app or a failed deploy. Each has its own switch.
EmailHow mail is sent (Resend or your own SMTP server), who it comes from, and the domain apps may send from.
SlackOne workspace bot that notifies owners and that published apps borrow.
MCP serversWhere the catalog under Admin, MCP servers reads its entries. You can always add a server by its address without any source.
Published appsWhat one app may use: memory, CPU, schedules, when idle and cold-start apps sleep, whether an app may ask to postpone a redeploy while it is busy, and the lookups for known vulnerabilities.
BackupsThe nightly backup of every app, and an optional copy in an S3-compatible bucket.
MonitoringAlerts to administrators, request counts per app, the time zone daily figures follow, and what happens to the apps of an erased person.
SchoolsSchool mode: assignments, student apps and the end of the school year. Off by default, and nobody sees any of it while it is off.
Server placementWhether an app moves off a full server on its own or waits for an administrator, and how often app files on other servers are copied to the main one, so a lost server can be recovered.
LicenceThe licence file, who it is made out to, the optional daily check-in, and Buy online.