Your own isolated instance, locked and backed up

Every customer gets their own dedicated instance (a separate, hardened container with its own encrypted storage and its own private network), running on a virtual server we operate with a hosting provider. Your Module runs there, and only there. Your documents and conversations are stored in our managed database, where every record carries your workspace's identity and every query resolves that identity from your signed-in session rather than from anything the caller supplies, so one workspace cannot request another's records. Your integration credentials go further: each workspace has its own encryption key, so they are not readable even with access to the stored data.

• A dedicated container per customer One instance, one customer, no shared runtime.
• A hardened container runtime We use a sandboxed runtime that intercepts system calls in user space rather than passing them straight to the host kernel, which shrinks the surface a container breakout would have to attack.
• A per-customer private network Instances cannot see or reach each other.
• An encrypted volume Your instance's persistent storage is encrypted at the disk layer.
• A read-only filesystem The container image itself cannot be modified at runtime; writes are confined to the explicit data volume.
• A restricted syscall profile A custom allowlist limits which kernel operations the container can perform at all.
• Non-root execution Nothing inside your instance runs as a privileged user.
• Per-customer resource limits CPU and memory are capped per instance, so a customer's workload cannot use more than its own instance's allocation.

Two supporting services are shared across customers rather than dedicated to one: web browsing, where enabled, and document embedding for knowledge-base search. Both run on shared, hardened infrastructure and hold no persistent customer data.

In transit

TLS 1.2+

All traffic between your browser, our application, your instance, and any third-party service is encrypted with TLS 1.2 or higher.

At rest

Encrypted

Your instance's storage volume is encrypted at the disk level. Integration credentials are encrypted with a separate key per workspace (Fernet: AES-128-CBC with HMAC-SHA256). Data held by our database and storage providers is encrypted at rest under those providers' own security programs, and backups are encrypted with our own key before they leave our systems.

• Managed identity provider Sign-in, sessions, and credential storage are handled by a specialist third-party identity provider. We do not store your password, and we do not roll our own session handling.
• Organization-scoped access Users belong to an organization, and every request is checked against the caller's organization before any data is returned. Access is derived from the verified session, never from an identifier supplied by the browser.
• Role tiers Members of an organization hold one of three roles (owner, admin, or member), which determine what they can view and change.
• Recorded staff support sessions When Raileon support staff need to look at your workspace to resolve an issue, they do so through a dedicated, explicitly marked support session. The start and end of each session are written to an audit log that we keep for 24 months. Staff administrative access to our servers, database keys, and backups is limited to the people who need it and is not recorded in that log.

• Customer data is never used by Raileon to train AI models, unless you hire us to train your own model. Then it's trained only for you, runs on your systems, and you own it.
• Our AI provider's commercial terms say it may not train models on customer content.
• We have not configured zero data retention, so a provider may keep API data for a limited period (for example, for abuse monitoring) under its own policies.
• If you connect your own AI provider account, that provider's terms for your account apply to what it processes, including whether it may train on your data. Some free tiers allow it, so use a paid account.

Every third-party provider we rely on, and the specific purpose each one serves, is listed on our sub-processors page.

Modules can act on your behalf, including sending email and posting to connected messaging channels. You are responsible for reviewing and approving communications that carry real consequences for your business or your clients.

• Daily backups of each customer's instance, plus a daily snapshot of our application database. The snapshot covers all customers together; it is not a per-customer backup.
• Encrypted before upload Every backup is encrypted with our own key before it leaves our systems. The database snapshot is exported by a scheduled job that may run on a GitHub-hosted runner, where the unencrypted export exists only until the job encrypts and deletes it.
• Stored separately from the running instance, in Cloudflare R2, so a failure of the primary host does not take the backups with it.
• Rolling expiry Backups expire on a schedule set by Raileon, so data deleted from our live systems can remain in backups until they expire. They are not restored or read except to recover from a failure.
• Restore check An automated job, designed to run weekly on our host, downloads the latest backup of a customer workspace, decrypts it and confirms it unpacks. That shows the backup is readable; it does not start a running copy of a workspace. A full restore into a running environment is carried out by hand when needed.

When a cancellation takes effect, your Modules stop running and you have a 7-day window to export your data yourself from your dashboard (Settings → Privacy & data → Export your data, for account admins). After that window your instance and its data are deleted; copies in backups expire on the schedule above.

• Application logging on the servers that run the platform, so activity can be traced and reviewed. Our deployment can also ship structured logs to a central search store when that is switched on.
• Error monitoring Application errors and exceptions are captured and surfaced to our team automatically.
• Operations alerts Failures, new inquiries, and support tickets are sent to our staff by email. An internal Discord channel gets only a short notice that something happened, without names, contact details, or message contents (see the sub-processors page).

What we ask

• Please do not run automated scanners, fuzzers, or brute-force tooling against our systems.
• Please do not degrade service, exfiltrate data, or access an account that isn't yours. If you stumble into someone else's data, stop and tell us.
• Please give us a reasonable window to fix the issue before disclosing it publicly.

If we confirm a security incident affecting your data, we will notify you without undue delay. Where the incident is a personal-data breach, we will notify affected customers within 72 hours of becoming aware of it, and we will tell you what we know, what we don't yet know, and what we are doing about it, rather than waiting until the picture is complete. The full contractual terms are in our Data Processing Addendum.

Requests from governments and law enforcement

We review every request from a public authority for customer data, challenge it where we have reasonable grounds to, and tell the affected customer promptly unless the law prohibits us from doing so. Where the Standard Contractual Clauses in our Data Processing Addendum apply, they set out these obligations in full.