Ciresk dev

Run your code in a session in the cloud while your editor and your coding agent stay on your machine: commands, services, a browser, code search, diagnostics and SSH, in your organization's region, under your organization's policy.

How it works

You run ciresk dev up in a git worktree. The dev API places a session for that worktree on a worker in your organization's cell and returns its URLs. Each worktree has its own session; running up again returns the same one.
The session is built from the repository's template, .ciresk/dev.yaml: the toolchains, the steps that prepare the workspace, the services and their ports, the browser and what may leave the session.
Your local worktree stays the source of truth. Every file you or your agent save locally reaches the session within a second, and the services rebuild from it. Nothing you edit lives only in the cloud.
Your machine reaches the session through an authenticated tunnel: each service is served at http://<label>.localhost:<port>, and ciresk dev ssh and ciresk dev code connect your terminal and editor.
The session stops when nobody has used it for its idle time, when you run ciresk dev down, or when your organization's policy ends it.

Concepts

Term	Meaning
Session	One running copy of a worktree's stack: its containers, services, browser and workspace. A session belongs to the person who started it, or to the person an agent or API key acts for.
Template	`.ciresk/dev.yaml` in the repository, or a version your organization published for it. It can declare parameters and presets a person picks at `ciresk dev up`. See Templates.
Worker	The machine a session runs on. A worker serves exactly one organization. Ciresk runs them in its cell, or your organization runs its own (Run sessions on your own workers).
Policy	Your organization's dev policy: who may sync, SSH, share and download, path rules, session limits, budgets, egress ceilings. See Administration.
Paused session	A remote session (`ciresk dev up --remote`) stopped with its workspace checkpointed, so `ciresk dev start` or an autostart schedule brings it back. See Sessions.
Generation	Each synced change of the workspace. Tools that wait on a change, such as `ciresk dev wait`, name the generation they wait for.
Member	Someone the owner shared a session with, as `view` or `use`.

Who it is for

Developers who want the whole stack running without installing it: start with the Quickstart, then Sessions and Editors and SSH.
Coding agents (Claude Code, Codex, Cursor) that need to run, test and look at the app they change: Agents and MCP tools.
Organization admins who govern access, cost and what leaves a session: Administration, Egress policy, Budgets and usage.
Security reviewers: Security.

Where it runs

Sessions run in the eu1 cell in AWS eu-central-1, on workers enrolled into your organization. A us cell is not available yet. Checks, tests and builds are not the session's job: they run on Ciresk CI, which ciresk ci drives with the same sign-in.

What is not available yet

Model access from inside a session. An agent runs on your machine and reaches the session through ciresk dev.
A public share link. Sessions are shared only with members of your organization.
Pushing from a session in eu1: see Git push from a session.