This guide takes you from a blank Code</>sensei account to a running deploy on a server you control. You will need three things before you start: a Linux server (any cloud VM, VPS, or self-managed box) with root SSH access, a Git repository containing your Django or Node.js application, and approximately ten minutes.

1. Register and sign in

Click Get started in the top navigation. Provide an email, a display name, and a password of at least twelve characters. Code</>sensei creates the account and signs you in immediately; there is no email-confirmation step on the free tier, so you can move straight on to adding a server.

2. Add your server

From the dashboard, click Add Server. The default authentication mode is SSH key. Provide the server's IP address or hostname, the SSH port (usually 22), and the operating-system login (usually root, or whichever account has unrestricted sudo).

When you submit the form, Code</>sensei generates an ephemeral Ed25519 keypair on its own infrastructure. The private half is encrypted with the field-level Fernet key configured for the platform and stored at rest; it is never transmitted back to your browser. The public half is shown to you with a one-line shell command to paste into your server's ~/.ssh/authorized_keys file. The pasted command also ensures correct directory and file permissions (700 on ~/.ssh, 600 on authorized_keys).

Once you have pasted the command, click I've installed it. Code</>sensei now opens an SSH connection from its worker to your server, attempting a non-interactive login with the private key it generated. The polling page flips from pending to ready as soon as that handshake succeeds. Typical detection latency is between five and twenty seconds. If the poll times out (default sixty seconds), check that you pasted the entire command including the trailing pubkey line and that no firewall is blocking inbound SSH from the Code</>sensei worker IP range documented in Security.

3. Create a project

From the dashboard, click New Project. Pick Git Repository as the source, paste the HTTPS or SSH clone URL for your repo, and pick a branch (defaults to main).

For Django projects, fill in the Django settings module field with the dotted path you would normally export as DJANGO_SETTINGS_MODULE — for example config.settings.production. Code</>sensei uses this to render the service unit file with the right environment.

For Node.js projects, leave the Django settings field blank. The requirements file path is reused for Node — the platform detects package.json at that path instead.

Environment variables go in the Environment vars field as a single JSON object. For example:

{"DATABASE_URL": "postgres://app:hunter2@127.0.0.1/app",
 "DJANGO_SECRET_KEY": "<long random string>",
 "DJANGO_ALLOWED_HOSTS": "example.com,www.example.com"}

Quote any value that contains the characters <, >, (, ), ;, |, or a literal space. The values are written through to a shared .env file on the server and sourced by every process the deploy starts, so the same shell-quoting rules that apply to a hand-written .env apply here.

4. Deploy

From the dashboard or the project detail page, click New deploy. Pick the server you just added as the target and pick Initial Deployment as the type. Submit the form.

Code</>sensei queues the deploy into the background worker queue (Celery, with a local Valkey/Redis broker per VM). The deployment-detail page that you land on subscribes to a WebSocket and streams the deploy log to your browser as the worker runs it.

Behind the scenes, the worker SSHes into your server, clones your repository at the requested branch into a release directory under /srv/codesensei/<project-slug>/releases/<timestamp>/, installs the application's dependencies, runs database migrations for Django projects, collects static assets, and writes a systemd unit that binds your application to a fresh socket. A reverse-proxy entry is appended to the edge configuration so the deploy can be reached at a unique <uuid>.apps.codesensei.cloud hostname.

The first deploy provisions the server's base packages, so it takes longer than subsequent deploys — typically two to four minutes for a Django project with a moderate dependency tree, faster for Node.js. After the worker reports success, click the rendered public URL to confirm your app is live.

5. Re-deploy and roll back

Subsequent commits on the same branch redeploy in seconds rather than minutes — the base provisioning is cached. Click New deploy, pick Update as the type, and submit. The worker pulls the latest commit, reinstalls only the dependencies that changed, runs migrations, and atomically swaps the symlink that points at the active release.

To roll back to a previous successful deploy, open the deployment detail page for the version you want to restore and click Roll back to this. The worker re-points the symlink without re-running migrations or re-installing dependencies, so the rollback completes in seconds.

Promoting a deploy to production

By default every successful deploy gets a unique URL of the form https://<uuid>.apps.codesensei.cloud. That URL is permanent and stable for the lifetime of the deploy — you can share it with a colleague for review or wire it into a staging integration test.

When you are ready to promote one of your deploys to the project's production alias (the canonical URL your users hit), open the deployment detail page and click Promote to production. The edge proxy updates atomically so the production alias starts serving the chosen deploy with no downtime; the previous production deploy keeps running and stays reachable at its uuid URL until you prune it or run out of release-directory slots.

Adding a custom domain

Promotion to production is what you do to swap which deploy your canonical URL points at; mapping your own domain on top of that canonical URL is a separate one-time setup. From the project detail page, click Custom domain, paste in the hostname you want to serve from (www.example.com), and follow the DNS instructions the page shows. The platform validates the CNAME, issues a TLS certificate from Let's Encrypt, and starts serving your custom domain in addition to the .apps.codesensei.cloud alias. Renewals are automatic.

Next steps

  • How it works — the platform's architecture and the role each component plays at deploy time.
  • Security model — what Code</>sensei can and cannot see on your servers, key rotation, and how to revoke access.
  • Troubleshooting — a checklist for the most common failure modes during initial deploys.