Fivexer

Security & data handling

What Fivexer stores, where it runs, who can reach it, and what we do not yet have. Written for the person who has to sign off on us — so it names the gaps as plainly as the controls.

Last updated 27 July 2026

Where your data lives

Fivexer Cloud runs on DigitalOcean infrastructure in Frankfurt, Germany (fra1) — inside the European Union. The Kubernetes cluster, the managed Postgres control plane, and the object-storage bucket holding attachments are all in that one region. Your routing data — tasks, workers, queues, and the decision traces that explain every match — does not leave it.

The company behind it is EU-based too: Fivexer Cloud is operated by Testreel OÜ, registered in Estonia (12592678). There is no US parent company in the ownership chain.

Two things do leave the region, and we would rather you learn that here than discover it later:

  • Transactional email. Verification, password-reset and worker-invite messages are delivered through SendGrid in the United States. The message and the recipient address reach them; no task content does.
  • The Worker-Portal Studio, if you use it. Building a portal with the AI editor sends your prompts and the portal's own source files to OpenAI in the United States. Workspaces that never open the Studio never reach it.

One region, not a choice. There is a single region today. Workspaces carry a region field, but it is not yet a setting you can pick, and we would rather say so than let the field imply otherwise. If you need routing data on your own infrastructure or in a specific country, the bring-your-own data plane below is the real answer.

What we store

Fivexer is a routing engine, not a system of record. It needs tags, weights and identifiers to decide who should handle a piece of work; everything richer than that is optional and travels only if you send it.

CategoryWhat it isWhere
AccountYour name, email address, a scrypt hash of your password, and email-verification state.Postgres (control plane)
Workspace configurationWorkspace name, plan, matching policy, learning settings, webhook endpoint and its signing secret.Postgres (control plane)
API keysA SHA-256 hash of each key. The raw key is shown once at issuance and never stored — we cannot recover it for you.Postgres (control plane)
Live routing stateTask ids, tags, priorities, queue and backlog state, worker ids with their tags and routing weights, and decision traces.Redis (data plane)
Task contentTitle, description, a free-form context object, and opaque references — only if you send them. Routing works without any of it: tags and weights are enough.Postgres (control plane)
Comments & attachmentsComment text with an author label; attachment metadata. Attachment bytes go to object storage.Postgres + object storage
Completed workWhen a task reaches a terminal state it moves out of Redis into an archive table with its tags, worker, result and the decision trace that explains the match.Postgres (control plane)

References you attach to a task are treated as opaque: we validate their shape and hand them back to you. The platform never fetches them, so a URL pointing into your own systems stays a string on our side.

Encryption & secrets

  • In transit: HTTPS everywhere, with certificates issued by Let's Encrypt and renewed automatically.
  • At rest: the managed Postgres cluster and the object-storage bucket are encrypted at rest by our infrastructure provider.
  • Passwords are stored as scrypt hashes with per-user salts. We never hold a raw password.
  • API keys are stored as SHA-256 hashes. The raw sk_ key appears once, at issuance.
  • Session tokens, email-verification links and worker-portal invitations are stored hashed and are single-use. An invite link that has been used cannot be replayed.
  • Bring-your-own Redis URLs — which carry your own credentials — are sealed with authenticated encryption before they touch the database, never stored in plaintext.

Backups

The two stores are backed up differently, and the difference matters if you are assessing what a bad day looks like here.

  • Control plane (Postgres) — accounts, workspace configuration, task content, comments, attachment records and the archive of completed work with their decision traces. Uses DigitalOcean's default automated backups for managed databases.
  • Data plane (Redis) — live routing state: what is queued, what is pending, and each worker's current backlog. Runs with append-only-file persistence on a persistent volume, single instance.
  • Attachment bytes live in object storage and are not covered by the database backups above.
  • Restores are tested, not assumed. We have restored the control plane from backup. A backup nobody has ever restored is a hypothesis, not a control.

What that means in the worst case. Completed work is durable — it lands in Postgres with its trace and is covered by managed backups. Live routing state is not covered by those backups, so a data-plane failure risks in-flight queue state rather than your history. If that risk profile does not fit your operation, the bring-your-own data plane puts Redis — and its durability guarantees — under your control.

Access

Fivexer is a small team. A small number of operators can reach production infrastructure, and they do so for two reasons: responding to an incident, and support you have asked for. We are not going to describe a formal access-review regime we do not run yet.

Inside the product, access is scoped by workspace membership. Browser sessions never handle a long-lived API key — the console authenticates with a session token and the sk_ keys stay server-to-server, so a key cannot leak through a dashboard tab.

No third-party analytics or advertising trackers ship with this site or the console. No Google Analytics, no session recording, no ad pixels. Nothing about your usage is sold or shared with an analytics vendor, because there isn't one.

Retention & deletion

Completed and cancelled tasks move out of the live routing store into an archive table, together with the decision trace that explains how they were matched. That archive is what powers the audit trail in the console.

Deleting a workspace deletes its data. Archived tasks, task content, comments, attachment records, notification history and workspace configuration are removed from the control plane; live routing state, usage counters and the workspace's Redis keys are removed from the data plane; and the attachment bytes in object storage are queued for deletion under that workspace's prefix. Workspace deletion is self-serve in the console.

To delete an entire account, email support@fivexer.com. We complete account deletions within 30 days of the request.

There is no automatic retention window yet. Archived tasks stay until you delete them or delete the workspace. If your policy requires data to age out after a fixed period, we cannot enforce that for you today — tell us what you need and we will tell you honestly when we can do it.

Subprocessors

Every third party that can process your data, what they do, and what actually reaches them. If this list changes, this page changes with it.

SubprocessorPurposeLocationWhat reaches them
DigitalOceanKubernetes cluster, managed Postgres, object storageFrankfurt, Germany (fra1)All platform data: account records, workspace configuration, routing state, task content you send, attachments.
SendGrid (Twilio)Transactional emailUnited StatesRecipient email address and the contents of the message — email verification, password reset, and worker-portal invitations. No task content.
OpenAIopt-in featureAI portal builder in the Worker-Portal Studio (optional feature)United StatesOnly the prompts and portal source files exchanged while building a worker portal in the Studio. Reached only by workspaces that use the Studio.

Certifications

We hold none of the usual ones. No SOC 2, no ISO 27001, no HIPAA attestation. No third-party penetration test yet, and no published uptime commitment — we will not offer an SLA before we run the on-call rotation that would back it.

What exists instead is on this page: a single EU region, encrypted secrets and hashed credentials, a deletion path that actually reaches object storage, no analytics vendors in the data path, and an engine you can run yourself if we disappear.

If your procurement process needs something specific — a questionnaire, a DPA, an architecture call — write to support@fivexer.com and you will get a straight answer about what we can and cannot sign today.

Getting your data out

The exit path is not a formality here — it is a design property, and it is the honest answer to "why is depending on a young vendor safe?"

  • Export any time, through the same API you write with. Tasks, workers and decision traces are all readable through /v1. No export fee, no plan gate, no support ticket.
  • The engine is open source. The routing engine underneath Fivexer Cloud is the MIT-licensed assignment-user-matcher. If the hosted product stops working for you — price, region, or us — the matching logic itself is yours to run on your own Redis.
  • Bring your own data plane. On Enterprise, routing state can run on Redis you own, so the live data never sits on our infrastructure at all.
  • The free tier has a stated ending. 60 days' notice before launch pricing changes, and workspaces created during launch keep the launch allowance for 6 months after that notice — see the launch terms.

Reporting a vulnerability

Email support@fivexer.com with enough detail to reproduce the issue. We acknowledge reports within 3 working days and will tell you what we are doing about it.

Please test only against workspaces you own, and do not run load or denial-of-service tests against shared infrastructure — other people's routing runs on it. We do not operate a paid bug bounty; we will credit you publicly if you would like that.

Security: support@fivexer.com

Data processing agreement: read our standard DPA — already in force, no request needed

Privacy: how we handle personal data