Your servers. One command.
The installer checks Docker, generates every secret, pulls pinned release images, starts the stack and prints the link that claims your instance. Add --wizard and it asks where your data lives first.
Release images
The installer pulls the release images it names. SalesOS has not published its own release images yet, so today the one-line install brings up the upstream warmbly release: the email platform, without SalesOS's approvals. To run SalesOS now, build it from source with the deployment guide. This note goes away with the first SalesOS release.
Read it first. Download, verify, read, run.
Piping a script into a shell is a fair thing to be wary of. The script is versioned, checksummed and written so a cut-off download runs nothing.
$ curl -fsSLO https://salesos.spinrun.ai/install.sh$ curl -fsSLO https://salesos.spinrun.ai/install.sh.sha256$ sha256sum -c install.sh.sha256$ less install.sh$ sh install.sh --wizard
The wizard. It asks what a config reference cannot ask for you.
Every answer has a default that matches the one-line install, and every answer is also a flag and an environment variable, so the same install runs unattended from Ansible or cloud-init.
Where it lives
One directory for the compose file, the .env and, unless you move it, every store the instance writes to.
How it is reached
The hostname every link is built from, and whether a bundled Caddy serves it with automatic HTTPS.
Where the data sits
Under the install directory, a path you choose, or Docker volumes. Bring your own Postgres, Redis or S3-compatible store if you like.
Keys and secrets
Every secret is generated for you. The two encryption keys are printed and written to a backup file, because losing them loses the data.
What is kept, and for how long
Import windows, event logs, the audit log and warmup records, each with a default you can shorten. A minimal retention preset is one answer.
Backups
A scheduled backup with a target, a frequency and how many to keep, and whether the keys travel in the bundle.
Who gets in
The first owner, the registration posture, and whether platform mail goes through your SMTP relay.
Footprint and review
Everything, or core only. Ports are checked before anything is written, and you review every answer before it runs.
Running it. Yours after the install, too.
Your own AI key
Set AI_PROVIDER to anthropic and add your key. Every model call is billed by Anthropic to you, with no markup. Leave AI unset and AI features answer cleanly that they are off.
Upgrades you control
The version is resolved once and pinned in .env, never latest. The backend applies its migrations on start, and workers follow it.
Backups and moves
With the stack stopped, moving to a new host is the data path plus the .env. A single workspace can also be exported and imported on another instance.
No phoning home
The only outbound call the instance makes on its own is an optional update check against GitHub releases. There is no telemetry.
Questions. Self-hosting, answered.
Do I need an account with you?
No. There is no hosted service, no licence key and no vendor account. Install it, claim the instance with the link it prints, and it is yours.
Can I read the script before running it?
Yes. Download it with its checksum, check the hash, read it, then run it. The --dry-run flag prints the exact .env and compose file it would write and touches nothing.
What if I already run Postgres or Redis?
Point the wizard at them and the bundled containers are left out. Blob storage can be the filesystem or any S3-compatible store; once workers run on several machines it has to be the latter.
How do I stay up to date?
Re-run the installer or follow the updating guide. A re-run adopts the existing .env, never regenerates a secret and never moves your data.
Self-hosting SalesOS is not a managed service. Nobody else runs, backs up or patches your instance, and as the operator you are the controller of the data it holds.
Install it on a server you control.
Start with the wizard, keep your keys safe, and connect your own Claude.