Your data, and who can see it¶
The questions people actually ask before putting something real on a box. Short answers here; the binding versions are the Privacy Policy and the Terms.
Where does my data live?¶
Paris, France. Your box, its disk, its volumes, and the control-plane database are
all in Scaleway's fr-par region. Nothing about your apps runs anywhere else, and
nothing is moved out of the EU/EEA without telling you first.
Two other places hold something, and it's worth knowing which:
| Where | What's there |
|---|---|
| Scaleway (Paris) | Everything that runs: your box, its disk and volumes, the control-plane database, DNS. |
| Microsoft Azure (EU) | Off-site backups of the control-plane database — so an incident at Scaleway can't destroy both the service and the means to rebuild it. Your app data isn't there, but see logs. |
| Stripe | Your card, name and billing email. They go to Stripe's own checkout page and never reach Allocus, which sees only a customer id and a status. |
GitHub sees that you signed in, at the moment you do it. That's the whole list.
What does Allocus know about me?¶
Less than you'd guess. Sign-in asks GitHub for the read:user scope and keeps only
your username — not your email, real name, or avatar. Alongside that: one contact
email address you type in yourself, hashes of your credentials, your box's name and IP,
your app config values, deploy records, and about four hours of rolling CPU/memory/disk
samples.
That's it. There is no analytics, no advertising pixel, no session recorder, no tracking cookie — one signed session cookie that remembers you're logged in, which is also why there's no cookie banner to click. The Privacy Policy lists every row in a table, because "we value your privacy" isn't a claim anyone can check.
Can Allocus log into my box and look around?¶
No, and not as a policy — as a network fact. Your box's firewall accepts web traffic from the internet and administrative access only from the control plane's own address range. And the control plane never opens a connection to a box at all: the box calls out, asks whether there's work, and does it.
That's why there's no SSH key for you to manage, and it's the reason every feature has to arrive as something the box asks for rather than something pushed at it. Diagnostic commands run because you requested them, through that same channel.
Direct administrative access exists — it has to, for a serious security problem or when you ask for help debugging — and it is not routine. That's written down in the data processing section of the Terms rather than left to trust.
Who can see your logs?¶
This one deserves a straight answer, because the mechanism has a consequence.
When you run allocus logs, your box is firewalled, so the output can't come to you
directly. Instead the box's agent runs docker compose logs, and the result travels
back through the control plane's database on its way to your terminal. Whatever
your app prints is in there.
Which means:
- Log output is stored in the control-plane database until it's superseded by a newer command or the box is torn down.
- Because that database is backed up off-site, log output can reach the Azure backups and stays there until the backup expires. Both sub-processors are named in the DPA for exactly this reason.
- The operator has access to that database. Nobody else does.
So: don't print secrets or your users' personal data into your application logs. That's good practice everywhere, and here it's the difference between data that stays on your box and data that leaves it.
Everything else about your apps — databases, uploaded files, volumes — stays on your box and is never read, indexed, mined, or used to train anything.
Backups are yours¶
The single most important thing on this page.
Your box is not backed up for you. Volume snapshots are taken on a best-effort basis and are explicitly not a service to rely on: there is no restore button, no point-in-time recovery, and no guarantee. If your box's disk is lost, what you get back is what you can redeploy.
The design assumes that's fine, because it assumes the value lives in two places you already control:
- your git repository — the code and the
allocus.yaml, - your container images — every deploy is tagged with an immutable git SHA, so
allocus rollback <sha>reruns an exact earlier build with no rebuild.
Databases break that assumption. A Postgres volume on your box exists nowhere else, and
nothing on the platform copies it anywhere. If you would be upset to lose it, arrange
your own backup off the box — a pg_dump on a schedule to object storage is the usual
answer, and it can be a one-shot service in your own stack.
What survives what
| Event | Your app data |
|---|---|
| A redeploy | Survives if it's in a declared named volume. The container filesystem is scratch and is recreated every time. |
| Changing plan (resize) | Survives. The machine keeps its disk and its IP; it's offline about a minute. |
allocus remove <app> |
Deleted along with the app's volumes, unless you pass --keep-data. |
| Cancelling your subscription | Deleted permanently when the paid period ends, along with the box. |
| Losing the disk | Gone. This is the case backups exist for, and you own it. |
Secrets and config¶
Anything sensitive belongs in the secret store, not in allocus.yaml and not in your
image:
allocus secrets set DATABASE_URL=postgres://…
allocus secrets list # names only — values are never shown back, to anyone
They're encrypted at rest, and they deliberately do not travel inside a deploy
instruction — the box fetches them on a separate request at deploy time and writes them
to the app's .env with 0600 permissions. Deploy records, which are kept, therefore
never contain a secret value.
Your API key and your box's credentials are stored only as SHA-256 hashes. The plaintext key is shown to you once and cannot be recovered afterwards, by you or by anyone else — if you lose it, you revoke it and make a new one.
If your app handles other people's data¶
Then you are the data controller and Allocus is your processor. That's not a formality you need to arrange: the data processing agreement is part of the Terms and takes effect when you accept them, with nothing to sign separately.
The commitments worth knowing about are the ones you'd otherwise have to go asking for:
- Two sub-processors, both named — Scaleway (compute, storage, network, DNS) and Azure (control-plane backups). At least 30 days' notice before another is added, and you may terminate if you object.
- Processing on your instructions only. No independent purpose, no profiling, no model training.
- Breach notification within 72 hours of it becoming known — by email, and posted on the public service notices page so it still lands if your address has gone stale.
- Deletion on termination, with the caveat that a copy may sit in a backup until that backup expires.
- Audit means a written answer, not an on-site inspection. Allocus is one person; pretending otherwise would be dishonest.
This is a genuine DPA and it is also a small one. If your compliance process needs something it doesn't cover, ask early rather than late.
Getting your data out, or deleted¶
You can ask for a copy of what Allocus holds about you, correct it, delete it, or object to a particular use — email the support address and a person handles it, normally within days and always within a month. If you think it's been handled badly you can complain to Datatilsynet, the Norwegian DPA, or to the authority where you live.
For the data inside your apps, there's nothing to request: it's on your box, and you have the access. Export it before you cancel — after the paid period ends, the box and everything on it are deleted, and that deletion is permanent.
One deliberate exception in your favour: when a box is torn down, its deploy queue, command history and load samples go with it, but your saved app config is kept, so that a rebuilt box works without you re-entering everything. Ask and that goes too.
The honest caveat¶
Allocus is early-stage software run by one person. Credentials are hashed, app config is encrypted, boxes are network-isolated, and everything is HTTPS — but it has not been independently audited, and nothing here should be read as implying it has.