How sinep.dev works

Getting started

sinep.dev is open by invitation. Once your account exists, sign in at sinep.dev with your company's single sign-on or the e-mail and password you were given.

1. Connect your git forge in Settings → git integrations, or add an SSH key in Settings.
2. Create a workspace from a repository. Its virtual machine starts in a few seconds.
3. Sign the agent CLIs in to your accounts in Settings → agents, then start an agent in the workspace.
4. Install the iOS or desktop app if you want notifications and widgets.

Workspaces

A workspace is one project with its own virtual machine: a Kata microVM with its own kernel, a full Linux toolbox, and only that project's files mounted. Agents in one workspace cannot see another workspace, another user or the host.

• Files, the agents' conversations and your home directory survive restarts of the virtual machine.
• Rootless podman is available inside, so agents can build and test container images. There is no Docker socket.
• Each workspace has memory, CPU and process limits, and each account has a disk quota. An agent stuck in a loop slows only itself.
• Freeze a workspace you are not using to free its memory. Its files stay, and the agents that ran are resumed when you unfreeze it.
• Tailscale per workspace (optional) lets agents reach your company network through your own tailnet, with access controlled by your Tailscale ACLs.

Agents and terminals

Claude Code, Codex and OpenCode run in real terminals inside the workspace. Each terminal lives in a tmux session, so closing the browser tab or losing the connection doesn't stop anything.

• Run as many agents as the workspace's resources allow, each in its own tab.
• The Agents page shows every agent in every workspace: working, waiting for you, or done.
• Instructions, skills and MCP servers you set in Settings → agents are given to all your agents.
• The sinep.dev MCP server lets agents open files and diffs in your browser, ask you decisions, send preview links and, if you allow it, read and write your chats.

Review and git

Everything an agent changes shows up in the review pane, file by file, with word-level highlighting.

• Stage a whole file, one hunk or a single line, then commit with a message.
• Push, pull and open pull or merge requests on GitHub, GitLab or Forgejo. These run on the server with your stored credentials, not inside the workspace.
• Checkpoints let you go back to the state before an agent's turn.
• Free-form editing is always allowed: you never have to route a change through an agent.

Plans with provenance

For larger work you can write a plan and apply it like a migration. sinep.dev creates a branch, runs the agent on the plan, runs your acceptance commands and commits the result.

• Each commit records which plan, agent, model and session produced it. The full transcript is kept in git notes, so a fresh clone contains the whole history.
• A plan never replays deterministically. Running it again is a re-roll: a new branch and a new record, never an overwrite.
• If something fails, the branch and working tree stay for you to inspect or take over. The target branch is never touched.

Decisions and notes

An agent that needs you doesn't stop and wait in a terminal you aren't watching. It logs a decision: a question, the context and two to five options with its recommendation. Then it carries on with what doesn't depend on the answer.

• Answer from the Agents page, a push notification or the iOS lock screen. The answer is typed back into the agent.
• Interventions are tasks only a person can do, like signing in somewhere or adding a DNS record. You mark them done, and the agent checks and continues.
• Notes tell you what an agent did that you should know about, like a deploy, without asking anything.
• To let someone without an account decide, share a link to one decision. They see only that question.
• Agents never ask for a password or key through a decision. Secrets go where they belong, like Settings → workspace credentials.

The assistant

The assistant is your own agent in its own workspace, set up under Agents → assistant. It can see and type into your agents in other workspaces, which plain agents never can.

• Ask it to start a task: it starts an agent on its own branch and checkout.
• It waits for the agents it gave work to and reports their results, or tells you when one is stuck.
• If you allow it, it can answer decisions within the rules you wrote. You still see every answer.
• Messages from chats or other agents reach it marked as data. It acts only on your words and your rules.

Jobs

A job is a message you wrote, typed into the assistant, into all your agents, into one workspace's agents or into one agent. It runs when one of its triggers fires.

• Schedule: a cron expression in your time zone, at most every five minutes.
• Webhook: an outside service calls the job's secret URL. Text it sends is added only if you allowed that, marked as data from outside.
• Chat: an unread message matches your rule, such as a direct message, a mention, a keyword, a sender or a condition in plain words. Messages that arrive together are delivered in one run.
• Inzyde: an event in your Inzyde organization, such as a task created or completed.

A trigger decides only when a job runs. The target and the message are always yours, and every job is limited in how often it can run.

Chats

Connect your chat accounts in Settings → chats and read them all in one inbox: Matrix (encrypted rooms included), Slack, Microsoft Teams, Signal, Telegram, WhatsApp Business and Gmail. You can connect several accounts per service.

• Agents can find a conversation, read it and answer it as you, through the sinep.dev MCP tools. Mail is never given to agents.
• Reply suggestions: for the conversations you choose, sinep drafts a reply or a reaction and waits for your click.
• Acting without asking is a separate switch per conversation, with strict limits on what and how often.
• Messages are always handled as other people's words, never as instructions.

Preview links

A web app running in a workspace, like a dev server or an API, gets a private link from the ports menu. An agent can also send you the link itself.

• Links work for one hour and can be revoked at any time from the ports menu.
• Previews are served from a separate domain, so code in a preview can never act as you on sinep.dev.

Credentials

By default, git credentials stay on the server and git operations from the buttons run there. If you want git, cloud CLIs or other tools to work inside the terminal, tick what to copy into your workspaces.

• SSH keys and forge tokens.
• Kubeconfig, AWS profiles, Google Cloud and Azure credentials, and any file in your home directory.
• Named environment variables for your own tools.

Anything you sync is reachable by the agents in those workspaces. If an agent finds a credential exposed in a repository, it logs it under Agents → leaks so you can rotate it. Only the kind and location are stored, never the secret.

Apps

• Browser: everything works in any modern browser, on desktop and on tablets.
• iOS: a Live Activity with your agents' states, home screen and lock screen widgets, push notifications, one-tap answers and dictation.
• macOS, Windows and Linux: a desktop app with notifications. On macOS also desktop widgets for agents, usage and decisions.
• Android: an app with the full cockpit, installed from a download we send you.

Teams and organizations

• Single sign-on: your organization signs its people in with its own OIDC identity provider, or with local passwords.
• Organization admins manage their accounts, their identity provider and their audit log.
• Share a workspace with colleagues: everyone with it works as a full collaborator and sees its decisions.
• Limits and quotas: admins can cap each account's workspaces, memory and disk.
• Runners: run your organization's workspaces on your own server with Docker and Kata. The runner connects out to sinep.dev; your code and data stay on your hardware.
• Activity: each person sees their own record of finished work. There is no leaderboard and no hour counting.

Security model

sinep.dev assumes that the code agents run can be hostile: packages and build scripts nobody has read. The design keeps that code inside its workspace.

• One microVM per workspace with its own kernel, mounting only that workspace.
• Internet access for agents, with the host, internal services, private and link-local ranges, cloud metadata and other workspaces blocked.
• Git operations from the buttons run on the server with hooks and risky configuration disabled.
• Model provider keys and chat sessions stay on the server. No tool hands them to an agent.
• Another user's workspace, chat or file is simply not found, never just forbidden.
• Admins see accounts and limits, never the content of workspaces.

Hosted sinep.dev runs in data centers in the European Union. For a security questionnaire or details, write to contact@sinep.dev.

Help

Using sinep.dev and stuck? Write to support@sinep.dev. For pricing, a trial for your team or a runner on your own hardware, use the contact form or write to contact@sinep.dev.