Documentation
8 long-form guides covering every part of Code</>sensei: getting your first deploy live, how the platform works under the hood, project-specific notes for Django and Node.js, the troubleshooting checklist, and the REST API reference.
These docs are written for engineers who already know how to ship code and want a precise account of what the platform is doing on their behalf — the names of the commands that run, the layout of files on disk, the environment variable contract, and the failure modes you are most likely to hit. Each article opens with a single paragraph that summarises the topic; if that paragraph answers your question, the rest of the article is the depth you would want for a second pass.
The library splits into five sections. Getting started is for the person reading the docs index for the first time: a step-by-step quickstart that takes ten minutes start to finish, and the server-side checklist that prevents the most common first-deploy surprises. How it works covers the platform's architecture: what the worker actually does on your server during a deploy, what gets written where, and the security model that defines what the platform can and cannot see. Project guides walk through the framework-specific deploy notes for Django and Node.js, including the build-step decisions and the systemd unit shape each project type ends up with. Operations is the troubleshooting reference for the failures that surface after you have shipped your first deploy. Reference documents the REST API that powers the dashboard and that any external integration speaks.
Every guide is written against the same platform you are using. The commands are copy-pasteable; the file paths are the literal paths your deploys land in; the environment-variable names are the ones the worker reads. If a guide diverges from what you observe in practice, that is a bug — please email reach-us@codesensei.cloud with the deployment ID and we will reconcile.
Getting started
-
10 min
Quickstart — your first deploy in 10 minutes
Walk through the full Code</>sensei deploy loop end-to-end: add a server, install the bootstrap public key, link a Git repository, run an initial deploy, and inspect the streamed log.
-
7 min
Preparing a server for Code</>sensei
Supported Linux distributions, the exact operating-system packages the platform expects, and the optional hardening steps that reduce the blast radius if anything goes wrong.
How it works
-
8 min
How Code</>sensei works — the deploy lifecycle
A detailed look at what happens between the click of Deploy and the moment your application is reachable, including the agent process, release layout, and rollback model.
-
6 min
Security model — what we can and cannot see
Read this before you point Code</>sensei at a server with production data on it. Covers SSH credential handling, field-level encryption, blast radius, and revocation.
Project guides
-
9 min
Deploying a Django project
Project layout, environment variables, migration order, static asset handling, the gunicorn invocation, and the common Django-side pitfalls that surface during a first Code</>sensei deploy.
-
6 min
Deploying a Node.js project
What changes for a Node target vs. Django: build step selection, the package manager the platform expects, and the process supervisor for long-running apps.
How to read these docs
If you are new to the platform, start with Quickstart. It takes you end-to-end through your first deploy: registering an account, adding a Linux server, installing the bootstrap public key on that server, linking a Git repository, running the first deploy, and reading the streamed log that comes back. Ten minutes from a clean account to a running, TLS-terminated public URL.
If you already shipped your first deploy and want to know what happens under the hood, read How it works. It is the operator's manual: which commands the platform runs on your server, where the release directories land, what the systemd unit looks like, how rollbacks work without re-running migrations, and how failures surface in the deploy log.
If you are about to point the platform at a server with real production data on it, read the Security model first. It documents exactly what the platform stores (SSH credentials, encrypted), what it does not store (your repository, your database contents), how to cut access immediately if you ever need to, and the blast-radius assumptions.
Hitting a deploy failure? Troubleshooting is the flat reference list of symptom → cause → fix for every failure mode common enough to have a name. The dashboard's deploy log is always the source of truth, but the troubleshooting guide tells you what to look for in it.
Building an integration? REST API reference documents the
/api/v1/ surface — the
account, alert, advertise, payment, and subscription endpoints that the dashboard
itself calls. It also covers the response envelope, the pagination contract, the
versioning policy that keeps the v1 surface stable, the webhook payload for deploy
events, and the programmatic-deploy pattern you would use from a CI pipeline.
Updates and changelog
The platform is an actively maintained product. New deploy-script capabilities, new framework support, and new dashboard surfaces ship continuously. We do not publish a release-by-release changelog — the platform's deploy machinery updates in place, so there is no version to pin — but every customer-facing change is announced in the dashboard's What's new banner and documented in the relevant docs guide before it goes live. If a deploy-script change affects what runs on your server, the change ships behind a feature flag that defaults off for projects created before the change date; it activates on the next deploy you run.
If a behaviour described in these docs does not match what you observe on your deployments, the docs are wrong. Email reach-us@codesensei.cloud with the deployment ID and we will reconcile the docs against the actual behaviour within one business day. The truth lives in the platform; the docs serve the truth.
For deeper questions — system design rationale, integration recipes, migration paths from other deploy platforms — the same email reaches a human. There is no ticketing form, no triage queue, and no "for support, please consult our community forum" deflection. You email us, we reply.