10Software teams · Softwareexample setup · demo data
Asharedqueue,sharedmemory,clearroles.
Three example setups for teams that write code. What changes is how many machines, which security preset and who approves what. The control plane on your Linux server, the work on your machines.
It runs on your own server: work files and records are stored on your infrastructure; content processed by AI goes to the model provider you choose, and data sent to external tools goes to the connections you set up.
Chat · shop-web
demo data
Fix the date format bug on the checkout page. If the tests pass, open a PR and deploy to preview.
10:31
Job draftRunning 3/5
Checkout page date fix
Project
shop-web
Machine
build-01 · Linux
Runtime
Claude Code
Branch
remyral/date-format
Merge decisionCode requiredMerged
remyral/date-format → main
Platform verification · passed
CI checks · passed
DeployCompleted
Preview is live
Environment
preview
Record
on the audit log
01Workflowfrom the chat or the editor
Fromcodetopreview
A job opened from the chat enters the queue, runs on a suitable machine on its own branch, passes verification and reaches the merge decision and a preview deploy.
Workflow · From code to preview
demo data
From code to previewSavedSaveRun
Last job · 10:58 · preview live
02Setup and flowTeam
Setup and flow
A software team with several projects and different roles.
Setup
Control plane
The company’s Linux server (recommended 4 vCPU, 8 GiB memory).
Workers
Linux build machines with the container profile; macOS and Windows machines where needed.
Security preset
Dengeli (balanced): risky actions are asked according to rules; a code is required for the events you pick.
Roles
Owners and admins across all projects; operators and viewers per project, by membership.
What a day looks like
01
Team members with the operator role open work from the chat or a form; the queue places it on a suitable machine by capacity, disk state and required runtime.
02
Shared memory carries the team’s rules and decisions to every agent the same way; a person accepts the lessons agents propose.
03
The job becomes a PR; verification, the merge decision and a preview deploy in one flow, on the audit log.
What changes
Who started and approved what is on the record; a viewer only sees the projects they are a member of. Usage and cost per runtime and account.
How it connects
You connect your repositories through GitHub, GitLab or Bitbucket and your deploy targets through Coolify or Cloudflare. The control plane runs on your Linux server, workers on your Linux, macOS and Windows machines; outgoing webhooks tell your CI or n8n what happened.
We don’t impose a ready-made flow; design your own, either with AI (describe it in the chat) or yourself (in the workflow editor).
Good to know
Model use goes through your own subscription or API accounts.
Machines
demo data
A screen from the console · The real console: machines, with capacity, health and runtimes on one screen.
03In the same areaSoftware
In the same area
Scenario 02 · Solo developer
Agents work overnight; one notification in the morning.
A single developer building their own product or working for a few clients.
Server and machines
A small Linux server (at least 2 vCPU, 4 GiB memory); your own Mac and a Linux server as workers, both connecting outbound.
Security preset
Serbest (free): approvals, merges and deploys pass without asking; machine management and force-push are still asked.
What a day looks like
01
In the evening you type “fix the tests, open a PR” in the chat; the assistant drafts a job and you approve it.
02
The job runs overnight on the Linux worker, on its own branch; a transient error is retried with growing intervals.
03
In the morning the result arrives as one notification; you review the change and make the merge decision.
How it connects: Your own Mac and a small Linux server connect outbound as workers; you open no inbound ports. We don’t impose a ready-made flow; design your own, either with AI (describe it in the chat) or yourself (in the workflow editor).
For a sensitive project you switch to the Dengeli or Sıkı preset with one setting.
You put daily and monthly caps on API-billed spend.
Home
demo data
The real console: home, with the approvals and jobs waiting for you.
Scenario 03 · Security-focused team
Every sensitive step passes a person and a code.
A regulated team, or one working on a sensitive codebase.
Security preset
Sıkı (strict): every sensitive action needs a person’s approval and an authenticator code; which events ask for a code is chosen one by one.
Network and secrets
Projects off or allow-listed. Runtime and API keys sealed to the machine; git and deploy tokens encrypted on the control plane, never seen by the agent.
What a day looks like
01
You pick event by event which actions need an authenticator code — and how long a code stays valid.
02
Jobs from untrusted sources (fork PRs, outside contributions) are never auto-approved and never run with full access.
03
The audit log’s chain is verified from the panel; the log is exported as JSON Lines and kept somewhere else.
How it connects: Projects run with the network off or allow-listed; outside systems open jobs with API tokens limited by scope, lifetime and IP range. We don’t impose a ready-made flow; design your own, either with AI (describe it in the chat) or yourself (in the workflow editor).
The audit log is protected by a hash chain; you keep the exported copy somewhere else.
A job waiting for approval pauses after 60 minutes and resumes where it stopped once a decision is made.
Security → Events
demo data
The real console: per-event verification, choose which actions need a code.
This example runs on the same infrastructure as all the others: Remyral on your own server, and we build your flow together in the pilot. Just describe the work you want to simplify and the tools you use in your application.
