Desktop Installer

Install Owlat on a bare Linux VPS straight from the desktop app over SSH — no terminal — with a live, animated provisioning timeline.

The Owlat desktop app can install and configure a fresh server for you over SSH. Instead of opening a terminal and running the one-liner, you point the app at a bare Linux VPS, fill in a short form, and watch each step provision in real time. When it finishes, the new instance is connected as a workspace automatically.

This is the same installer as the CLI path — the desktop just drives it remotely and renders the progress. Anything you can do here you can also do with owlat quickstart.

When to use it

  • You want a GUI install with no SSH/terminal work.
  • You're setting up a server for someone less technical.
  • You like watching a progress timeline more than reading log output.

Prefer the terminal? The one-liner installer and owlat quickstart do exactly the same thing.

Prerequisites

RequirementNotes
A fresh Linux VPSUbuntu/Debian recommended; 4 GB RAM (8 GB recommended), 20 GB disk
SSH accessA user with sudo (or root), via private key or password
The Owlat desktop appDownload from the releases page
A domain + DNS controlOnly for remote access — see Remote access below

Docker does not need to be pre-installed — the installer adds it if it's missing.

Walkthrough

  1. Open the app → "Set up a new server". On the welcome screen (shown when you have no workspaces), choose Set up a new server.
  2. Enter SSH details. The server address, port (default 22), SSH user, and either a private key (paste it, with an optional passphrase) or a password.
  3. Verify the host key. On first connection the app shows the server's SHA256:… fingerprint. Confirm it matches your server, then Accept & continue. No credentials are sent until you accept — this protects against a man-in-the-middle. The fingerprint is remembered for next time.
  4. Configure the install. Pick feature packs (Email client, Marketing, AI), your email sending provider (Owlat MTA, Resend, or SES), an optional AI provider, your admin account, and — for remote access — a public domain.
  5. Provision. The app runs the install and streams progress into an animated timeline: connect → check the server → install Docker (if needed) → fetch Owlat → start the stack → deploy the backend → create your admin account. A collapsible server log shows the raw output if you want detail.
  6. Open workspace. When it's done, click Open workspace — the app connects to the new instance using the normal browser sign-in handshake.

Remote access

By default the install is localhost-only — reachable on the box itself, which is fine for testing but not for daily use from your laptop. To make it reachable, enter a public domain in the configure step.

That serves the stack over HTTPS at three subdomains (the convention used by Caddyfile.example):

SubdomainServes
owlat.<domain>the web app
api.<domain>the Convex sync backend (WebSocket + HTTP)
rest.api.<domain>Convex HTTP actions (auth, webhooks, tracking)

When you provide a domain, the installer generates a Caddyfile and enables the tls profile automatically — Caddy provisions Let's Encrypt certificates on first boot.

DNS + ports are your responsibility

Before provisioning with a domain, create A-records for owlat., api., and rest.api.<your-domain> pointing at the server, and make sure ports 80 and 443 are open. Caddy can't issue certificates until DNS resolves to the box.

How it works

The desktop app holds the live SSH session natively (Rust, via ssh2) and never re-implements the install — it drives the existing owlat quickstart with machine-readable progress:

  • OWLAT_PROGRESS=json makes the installer emit one structured event per step; the app parses those off the SSH stream to drive the timeline, and shows everything else as raw log.
  • The configuration you enter is written to a .owlat-setup.json file on the server and consumed by the installer's --config path (fully non-interactive).
  • The installer always talks to the backend over localhost on the box, so a domain install still provisions correctly before DNS/TLS are live.

Security

  • Credentials are sent only after you accept the host key, are held in memory for the session, and are not written to the log.
  • The native SSH commands trust the app's own bundled UI (the same trust level as the keychain access the app already uses). The app never loads remote web content into its window.

Troubleshooting

  • "Host key has CHANGED" — the server presented a different key than last time. Only continue if you know why (e.g. you rebuilt the box); otherwise stop and investigate.
  • A step fails — open the server log in the timeline for the underlying error. Steps are idempotent, so once you've fixed the cause you can start over and re-run safely.
  • Can't reach the instance after install — confirm the three DNS A-records resolve to the server and that 80/443 are open, then give Caddy a minute to issue certificates.
Building from source?

The remote install runs the ghcr.io/wolvesdotink/setup container, so a from-source build must publish that image from the same revision as the desktop app.