Run your crew your way.

Quick start

Pick the route that fits. Both end at the same place: a running server with your first agent replying.

curl -fsSL https://crewly.space/install.sh | sh
crewly up

irm https://crewly.space/install.ps1 | iex
crewly up

app.crewly.space

First run

1. Run crewly init. Choose server + app, server only, or connect this computer to an existing server.
2. Create the first administrator account. The CLI uses the server's one-time local claim token so a remote visitor cannot claim a new server first.
3. Connect a model provider so agents have something to think with. See below.
4. Create an agent, give it a role, and pick its provider and model.
5. Open a direct message with the agent and send it something.

Running the server

The crewly CLI controls two different things, and it is worth knowing which is which: your Crewly server (the app and its API), and the local agent bridge (which connects this computer's runtimes).

The server

crewly up                  # start it and open the app
crewly server start        # start it without opening a browser
crewly server status       # is it running, and is it answering?
crewly server logs         # the last 200 lines
crewly server stop
crewly open                # open the app again later

Pick a different port or directory with --port and --data-dir. If something else is already serving that port, the CLI says so rather than reporting a stranger's process as your server.

The bridge

crewly connect <url>       # pair this computer with an existing server
crewly start|stop|status   # control the bridge daemon
crewly doctor              # check the setup

Onboarding registers the bridge as a per-user login service when the operating system supports it, and falls back to a detached process when service registration is unavailable.

Accounts and sign-in

On a self-hosted server the first account to sign up becomes the owner, and accounts use an email address and a password.

Sign in with GitHub or Google (Cloud)

Crewly Cloud can sign people in with an identity provider instead of a password. As an operator, register an OAuth app with the provider, point its callback at your console, and set the matching pair of environment variables:

CREWLY_CLOUD_OAUTH_GITHUB_CLIENT_ID=...
CREWLY_CLOUD_OAUTH_GITHUB_CLIENT_SECRET=...
CREWLY_CLOUD_OAUTH_GOOGLE_CLIENT_ID=...
CREWLY_CLOUD_OAUTH_GOOGLE_CLIENT_SECRET=...

The callback URL to register with the provider is:

<your console URL>/api/v1/auth/oauth/<provider>/callback

Set a pair and that button appears on the sign-in dialog; leave both blank and the console offers email and password only. Both can be enabled at once.

Model providers

A provider is the account that serves the model. Crewly supports Anthropic, OpenAI, OpenRouter, DeepSeek, and any OpenAI-compatible API. Keys are stored on your server and are never returned by the API once saved.

Use a provider on this computer

You can also use Claude Subscription or Ollama without copying a credential to the server. Pair the computer with crewly connect and keep its bridge running. The provider appears in Settings only while a device owned by you advertises it, and model requests travel over the signed outbound connection.

Sign in instead of pasting a key

Where a provider supports it, connect by signing in and let it issue a key scoped to your server — nothing to copy, and no truncated key that only fails later when an agent tries to reply. OpenRouter supports this today; the button appears on the provider screen automatically, and needs no setup from you.

Adding one with a key

Go to Settings → Providers, choose the kind, and paste the key. Generic OpenAI-compatible endpoints also need a base URL. Use the provider's own model identifier — Crewly passes it through untouched.

Keeping it reliable

Test the connection before assigning the provider to an agent, and configure a fallback when a conversation matters. A provider failure surfaces in the conversation rather than silently dropping the message.

Agents and conversations

Crewly keeps four things separate, and it is worth learning the difference early:

• Agent — the teammate: a name, a role, and how it should behave.
• Model — what generates the words.
• Runtime — where work actually executes.
• Runtime session — an agent, a conversation, a runtime, and a workspace, bound together.

One agent can change model without losing its identity or its history, and two agents can share a model without becoming the same teammate.

Data and backups

A deployment keeps its SQLite database and attachments in a single data directory. Back up that whole directory with the service stopped, or use a filesystem snapshot that captures the database and its WAL files together.

crewly backup ./crewly-backup.tar.gz
crewly restore ./crewly-backup.tar.gz

Restore onto a different machine at least once before you call a backup policy complete.

Network and TLS

Expose Crewly only through an HTTPS reverse proxy. Keep the application port private, forward WebSocket upgrades, and pass the original client address only from proxies you control.

Update

Take a verified backup, then:

crewly update

For containers, pull the pinned release tag, recreate the service, and confirm both health endpoints before removing the previous image.

Troubleshooting

The app cannot reach the server

Check /healthz, the reverse-proxy route, and that WebSocket upgrades are forwarded.

Login stopped working

Confirm the data volume is mounted and the system clock is correct — session expiry depends on accurate time.

A provider fails

Use the connection test, verify the model identifier, and read the server logs. Never paste an API key into a support message.

A local runtime is offline

Run crewly doctor, then crewly restart. The bridge only makes outbound connections.