Work files on your infrastructure, access on your rules.
Remyral runs on your own server, with work files and records stored on your infrastructure. You define access and approval steps. Content processed by AI goes to your chosen model provider; data sent to external tools follows the connections you configure.
The questions data owners and process managers ask.
Where is it stored?
Panel, database, queue, vault and audit log on your Linux server; work files, workspaces and logs on the machines of yours that run the jobs.
DetailsWho can access it?
Team members get access by role: owner, admin, operator, viewer. Chats are private to each person; the assistant only works with your permissions.
DetailsWhich steps need an approval?
You decide with a preset and per-event choices, and you can put an approval step in a workflow. Machine management, force-push and security-setting changes are asked in every mode.
DetailsWhat data goes out?
Content processed by AI goes to the model provider you choose, and data sent to external tools goes to the connections you set up; network access is off, allow-list or web per project. Git and deploy tokens are stored encrypted on the control plane and never sent to a worker or the model.
DetailsWhich records can be reviewed later?
Privileged actions and state changes are on the hash-chained audit log; job logs and the usage and cost screens are in the panel. You verify the chain from the panel and export the log.
Details
Layered security
The sealed vault at the core, the audit chain on the outside. Each layer is designed to cover what the one before it cannot.
- 01
Sealed vault worker key
Secrets such as runtime and API keys are sealed with the key of the machine that will use them. The control plane (master) cannot open a value; only that machine can. A key pasted into the chat goes straight into the vault. Git and deploy tokens are not in this vault; they are stored encrypted on the control plane.
- 02
Sandbox isolation
Every job runs in an explicitly scoped workspace: a container on Linux, the runtime sandbox, or a restricted account on the machine. On Windows, parallel jobs each get their own account with process, memory and CPU limits.
- 03
Network policy egress
Per project: off, allow-list or web. Local network and cloud metadata addresses are always blocked.
- 04
Signed releases ed25519
Worker updates are signed and roll out gradually. Control-plane releases come as a signed bundle too; the installer verifies every file and pulls images by digest.
- 05
Audit chain hash chain
Every privileged action and state change is written to a tamper-evident (hash-chained) log. You verify the chain from the panel and export the log.
What we claim, how it works, where it ends.
Every security claim has a precondition and a limit. This table is the public summary of our internal threat model.
| Claim | How it works | Limit / precondition | How you verify it |
|---|---|---|---|
| Secrets stay on the machine | Runtime and API keys are sealed in your browser, separately for each machine they go to; the control plane only carries the ciphertext and only the target machine can open it. | Git and deploy tokens (the GitHub App key, Coolify and Cloudflare tokens) are stored encrypted on the control plane; they are never sent to a worker or the model. A new machine needs the value entered again. | Settings → Credentials shows each machine’s state (applied / needs re-seal); a value is never shown again. |
| Tamper-evident audit log | Every privileged action and state change is written to a hash-chained log. | The chain reveals later changes; on its own it does not prevent deletion. Keep the exported copy somewhere else. | Verify the chain on the audit log screen; export it as JSON Lines. |
| No inbound ports | Workers connect to the control plane outbound. | The reverse proxy’s HTTPS port is open on the control plane; workers must be able to reach that address. | Check listening ports on the worker with your OS tools; the machine shows as online in the panel. |
| Jobs run isolated | Every job runs with a sandbox profile: container, runtime-sandbox or host-restricted (a separate account per job on Windows). | The profile must be ready on the machine; the container profile needs rootless Docker or Podman on Linux. Jobs on one machine share localhost ports and the process list. | Machines → machine → the Sandbox & policy card shows whether each profile is ready, and why not. |
| Network access is limited | A network policy per project: off, allow-list or web. Local network and metadata addresses are always blocked. | In a project set to “web” the agent can reach the internet; maintaining the allow-list is up to you. | The policy is shown in the project settings; test the limit yourself by having a job call an address outside the allow-list. |
| Releases are signed | Control-plane and worker releases are signed; the installer verifies the signature and every file and pulls images by digest. | Trust rests on the trusted key in the script: compare it with the key id in the release announcement. | Run the installer as a dry run first; it prints every verification step. |
| Sensitive steps need approval | Sensitive actions go through a policy check; the events you pick require an authenticator code. | Under the Serbest (free) preset, approvals, merges and deploys pass without asking. Machine management, force-push and security-setting changes are asked in every mode. | Security → Presets and Events; automatic decisions show up on the audit log as “approved by policy”. |
Who sends what, where?
- You use the console in the browser over HTTPS. When you add a runtime or API key, it is sealed in your browser, separately for each machine it goes to.
- The control plane only carries the sealed (encrypted) value and cannot open it.
- Workers connect to the control plane outbound (WSS); no inbound ports are opened on the machines. Only the target machine opens a sealed value.
- The agent runs on the worker under the chosen sandbox profile; model calls go from the worker to the model provider you choose and are subject to the provider’s terms.
- Git and deploy tokens are stored encrypted on the control plane. For commit and push a short-lived git token is minted per push; deploys and DNS changes are carried out by the control plane itself.
You choose how much freedom it gets.
The three presets are three readings of the same rules. Separately, you pick event by event which actions require an authenticator code — and how long a code stays valid.
- Serbest (free)Approvals, merges and deploys pass without asking. For closed teams.
- Dengeli (balanced)Risky actions are asked according to rules; a code is required for the events you pick.
- Sıkı (strict)Every sensitive action needs a person’s approval and a code. For regulated teams.
Per-event verification: choose which actions require an authenticator code.
- Machine management, force-push and security-setting changes are asked in every mode.
- Pushing or merging to a protected branch, deploys, deleting outside the workspace, reading a secret, raising a budget and vault operations are never left to the agent; they always go through the master’s policy check.
- Jobs from untrusted sources (fork PRs, outside contributions) are never auto-approved and never run with full machine access.
- Automatic decisions are logged as “approved by policy”.
Full machine access (unconfined) only opens when both the machine and the project explicitly allow it, with a fresh authenticator code; owners are notified. A machine can forbid it locally altogether.
The agent never sees the credential.
Short-lived git identity
Git credentials are minted per job, at the moment of use — a short-lived token per push. The platform does the commit and push.
Encrypted integration keys
GitHub, GitLab and Bitbucket keys are stored encrypted on the server, never shown again and never sent to the model.
The assistant acts as you
The chat assistant runs on a worker you choose, not on the server. It has no shell or file access; it only uses the panel’s tools, with your permissions.
Approved machine pairing
A new machine isn’t trusted until you compare its pairing code and fingerprint and approve with a code. The install commands in the panel carry no secrets.
Owner account
The first sign-in connects an authenticator app and issues 10 recovery codes.
Untrusted content is data
Instructions in repositories, pages read and READMEs are never treated as authorisation for sensitive actions — only as data.
No inbound ports.
- Outbound only. Workers connect to the control plane themselves; no inbound ports on your machines, no static IP needed.
- One entry point. On the control plane, only the reverse proxy’s HTTPS ports are published.
- No calls to internal addresses. Outgoing webhooks are never sent to local-network, loopback or metadata addresses; only an owner can allow-list an internal target, with a code.
- Workflow requests run on workers. HTTP and code nodes run on a worker under the project’s allow-list and cannot reach private network addresses.
Audit log: every privileged action on one line, with chain verification and JSON Lines export.
Who can do what?
Owner and admin apply across all projects; operators and viewers only see the projects they are members of. The account role is a ceiling: a project membership cannot exceed it. Management actions need an authenticator code entered within the last 10 minutes.
| Permission | Owner | Admin | Operator | Viewer |
|---|---|---|---|---|
| See jobs, approvals and the usage summary | yes | yes | yes | yes |
| Create and cancel jobs, request a merge | yes | yes | yes | no |
| Approve or deny approval requests | yes | yes | yes | no |
| Write to project memory | yes | yes | yes | no |
| Project policy, budgets, git connection and memberships | yes | yes | no | no |
| Approve, configure and revoke machines | yes | yes | no | no |
| Read, verify and export the audit log | yes | yes | no | no |
| Create user accounts, change roles, disable accounts | yes | no | no | no |
An approval request’s own approver role and memory documents’ read/write roles apply on top. Every refused management request is written to the audit log.
Every door to the outside has its own rule.
- API tokens
- Read, job write, approvals, deploy and admin scopes; expiring, optionally limited to IP ranges. A token can never do more than its account’s role, and actions that need a code are refused for tokens by default.
- Outgoing webhooks
- Every delivery is signed with HMAC-SHA256 and carries a timestamp; retries of the same delivery share one id. Bodies contain no prompts, logs or secrets.
- MCP servers
- Off by default per project; allow / ask / block per tool. Tokens stay in the vault and never appear on a command line. Every tool call is audited (name, duration, result).
- Skills
- Imports go through a preview and a code-confirmed approval and are signed with the panel key; the machine verifies the signature again. A project can accept offline-signed skills only.
Problems show up before they grow.
Key and certificate expiry
API keys, integration tokens, the TLS certificate and signing keys in one list; reminders 30, 14, 7 and 1 day ahead.
Rollout circuit breaker
If updated machines fail, or their jobs fail noticeably more often, the rollout stops on its own; resuming or rolling back needs a code.
Cost brake
Daily and monthly caps on API-billed spend; warn only, or hold non-urgent jobs.
Rate limits
Adjustable read and write limits per person, per API token and for the chat.
Masked logs
Tokens and passwords are masked in log search; the support report excludes passwords, tokens, keys and job outputs.
Backups
A nightly database backup with a restore drill; optionally the backups also carry the key files, encrypted to your own age key.
Found a security issue?
Please email us the details, ideally with the steps to reproduce the issue.