DOCS · DEPLOYMENT

Remote use

Cortex is designed so the browser and development machine do not need to be the same computer. A workstation, NUC or VPS can host the backend while you control the agent from another device.

Remote Cortex should still be deployed deliberately.Cortex now requires browser authentication and can optionally add TOTP or Google sign-in, but the backend remains a high-authority development service capable of running commands and modifying repositories. Prefer HTTPS and a trusted network or reverse proxy when exposing it remotely.

Authentication

First-run password creation happens entirely in the browser. After setup, unauthenticated requests to protected workspace, provider and agent APIs are rejected by the server. For stronger login protection, enable TOTP under Settings → Security; Google sign-in can also be configured for one explicitly allowed Google email address.

Why remote matters

The machine running Cortex owns the repository, toolchain and agent process. Your laptop only needs a browser, which makes high-memory remote development machines practical without reproducing a full desktop environment.

HTTPS with Caddy

For Internet-facing deployments, the recommended simple setup is to keep Cortex behind Caddy and let Caddy terminate HTTPS. See HTTPS with Caddy for the simplest setup, or HTTPS with nginx if nginx already fronts your services.

Explicit proxy mode

cortex --listen 127.0.0.1:7331 \
  --trust-proxy \
  --public-origin https://cortex.example.com

Proxy trust is off by default. With this mode enabled, Cortex accepts forwarding headers only from its direct loopback peer and pins Host, secure-cookie, OAuth callback and same-origin checks to the configured public origin. Keep port 7331 private.

Capacity and overload

A Cortex process accepts up to 128 concurrent HTTP requests and four simultaneous agent runs. Saturation returns 503 Service Unavailable with Retry-After: 1; clients may retry after backoff. SQLite uses at most eight connections.

The browser retains at most 32 open conversations, 20 closed conversations and 500 events per open tab. Server conversation searches stop at 250 results. These bounds protect a single node; actual useful concurrency depends on models, workspaces and host resources.