The personal data your app keeps here
This page is about the data your own app collects from its users, not your enquiry to us. It covers where that data sits, who can reach it, how long a copy lives, and what deleting it actually does.
"Your data" means two different things on this site
Only the second one is this page's subject.
You
Your enquiry
The name and message you type into the quote form. We are the controller of that data, and Privacy states in full what we do with it. Privacy
Your users, through your application
Your app's data
Any personal data your own app collects, stores, or processes on hosting we run — an account, an order, a message, an uploaded file. This page owns that half. Databases
Where a user's data sits, store by store
The same stores Databases and Files already name — this page says what goes in each one.
A database
A table a user account, an order, or a message sits in. Sizing runs from DB Standard to DB Plus — see Databases for the full ladder.
A file
An upload, an export, or a generated document. See Files for where a static site, a dedicated instance, and a Custom shape each hold one, and what "no writable disk" means for the first of those.
A log line
A request or an application record that happens to name a user. Logs and § 04 below both cover what a log line does and does not hold.
A third-party service
Anywhere your own app sends personal data onward — a payment gateway, a mail sender, a customer-messaging tool. § 06 covers this on its own.
- Static
- A static site has no writable disk. There is nowhere to put an upload. A static plan has no store of its own — personal data your app handles goes to a database or a third-party service instead, never to a disk here.
- Dedicated
- The instance's own disk, sized into the tier's flat rate. Not a metered add-on.
- Custom
- Durable storage sized and priced for what you actually keep, the same as any other Custom shape.
Who can reach it, and on what terms
Access already names the four principals — this page asks only what each one can read.
Your team
The people at your organisation who already hold a key: push access to your own repository, and whatever DNS or registrar login you choose to keep for yourselves. It cannot reach anything on our side directly. There is no console, so a secret's value, a shell, or a live database goes through a request, not a click.
CustomHosted engineers
The people who provision, watch, and fix your stack — named accounts, not a shared login. It cannot merge or deploy to your repository on its own initiative. Only your own team can, unless you have asked us to hold that step for you.
The deploy pipeline
The automated system that builds, checks, and ships every merge — the same one for every change, agent-authored or not. It cannot decide to merge or open a pull request. It only ever acts after a person has decided.
The CodeHerder agent
Turns a plain-language brief into a pull request, under the Agentic iteration — CodeHerder add-on ($25/mo). It reads your live repository and writes on its own branch. It cannot merge, deploy on its own, read a secret’s value, or open a shell. A person approves the pull request, and the same pipeline you already run ships it.
Named accounts, not a shared login
Every engineer who can reach your stack signs in as themselves — never a shared password the whole team knows.
A key is scoped to the one job it does
Deploying your app, reading your backups, running your database — each is its own scoped key, never one master key that opens everything.
SSH is off by default
A shell on a dedicated instance is available on request, key-based only, scoped to what is needed — never left open because nobody asked for it.
Access changes when a job does
It is not left standing after it stops being needed — see joiners and leavers below for exactly when it is removed.
Every copy of it, and how long each one lives
The live store is one copy. A backup, a log line, and a staging copy are three more — each with its own lifetime.
| Copy | Lives in | Retention | What that means |
|---|---|---|---|
| The live store | The database or disk your app writes to | Until your app deletes it, or a user asks you to | The one copy your own application controls directly, end to end. |
| A backup — Every plan, by default | A separate, encrypted backup store | Daily backups · 7-day retention | Up to 24 hours — the gap since the last nightly backup. |
| A backup — Extended backup retention (30-day) | A separate, encrypted backup store | Daily backups kept for 30 days instead of 7. | Same 24-hour gap, further back in time to ask for. |
| A backup — DB Standard | A separate, encrypted backup store | 7-day PITR | Minutes, not hours — roll back to just before the write that broke it. |
| A backup — DB Plus | A separate, encrypted backup store | 30-day PITR | Minutes, not hours — roll back to just before the write that broke it. |
| A request log | The logging pipeline | Request logs kept 90 days | What a visitor typed or posted is not written down. Only that a request happened, and what came back. A visitor's address and the page they asked for are the parts that stay. |
| A staging copy | The staging environment, where one is provisioned | As long as the staging environment itself exists | A copy of production data used to check a change before it ships carries the same personal data as the live store, and needs the same care. |
Where it can leave, and who it goes to
Every outbound call is a place personal data can go — Outside services owns the call itself, this page owns naming it.
An outbound call — Static Starter
No standing server, so nothing here can hold a secret at all. A call to an outside service has to run from the visitor's own browser, out in the open. That's fine for a map or a widget. Never for a payment key.
An outbound call — Dedicated M
A standing process makes the call from the server side. Every instance ships with its own static IP. That's exactly what a payment or banking API wants for an allowlist.
An outbound call — Custom
Whatever mix of browser-side and server-side calls the design needs, sized and confirmed once, at the quote stage.
Outbound mail
A password reset or a receipt an app sends rides the same outbound path as any other mail. Email names 4 ways that path fails.
Deleting it takes longer than one click
The one fact this page exists to state plainly.
Deleting a row is not the same as erasing it everywhere
Your app can delete a row from its live database today. That row still exists in every backup taken before the delete.
A copy leaves only when its own window rolls past it
The default window is "Daily backups · 7-day retention". The longest we sell is "30-day PITR". Either way, the copy leaves on its own schedule, not on your delete's. See § 05 for the full copy table.
This is normal, and it is why the honest answer takes two sentences
A backup exists to bring back something that was deleted by mistake. It cannot do that job and also disappear the instant a real delete happens.
What survives the same delete
The pack you leave with includes backup archives. A row you deleted can still sit inside one, until that archive's own window rolls past. See Portability for the full pack. § 10 below ships a delete-my-account endpoint that reaches every store at once.
When it goes wrong, who tells you and how fast
The same first hour Incidents already runs for any other failure — a leak of personal data gets no separate process.
- 1
It starts
A watch signal trips, or you write in yourself.
Auto
- 2
Confirmed
The signal is checked from more than one vantage point before a person is pulled in.
Auto
- 3
Triaged
A human decides whether this is a platform fault or a bug in your own code.
Us
- 4
You hear from us
A written note goes out on the same quote channel as everything else.
Us
- 5
It's worked
An outage is worked ahead of the routine queue, not behind other requests.
Us
- 6
Out of hours
The same priority applies, but the response is best effort, not a staffed desk.
Us
- 7
It's closed
You confirm it looks right on your end.
You
See Incidents for the full first hour, and Monitoring for the escalation ladder behind it.
This site's own data, as the worked artifact
Every row below is checked against the built site, not a claim on its own.
No login, no stored password
There is no account to have a password for, and no store that could hold one. check:logins enforces it against the built site.
One form, seven capped fields
The quote form is the only way personal data reaches us through this site, and check:forms enforces the cap on every field.
Request logs, kept 90 days
Every request to the form is logged for 90 days, not kept forever and not thrown away immediately. check:forms holds that figure against the log group that enforces it.
One allowlisted third-party host
1 outside host loads on this site, named in Performance's own allowlist check — nothing else calls out with a visitor's data.
One region, in the United States
This site and its quote relay run in one region, in the United States. Naming a country is not naming the vendor underneath it.
Changing what you keep is a code change
A consent flow or a deletion endpoint is not a hosting setting to switch on — it is a pull request.
Add a consent checkbox to a form
A small, well-scoped change to a form your app already renders — the kind of pull request CodeHerder ships end to end.
Add a delete-my-account endpoint
A route that clears a user's rows and their uploaded files together, so a delete request reaches every store it needs to in one pass.
Add a scheduled job that drops old records Background jobs
A recurring job that removes records past a set age — a background job, the same shape Background jobs already covers.
- 1
A routine scan flags a dependency
The same kind of check that watches the infrastructure layers above, run against your application’s own dependency list.
CustomHosted
- 2
It's triaged as application-level, not infrastructure
A library your own code imports isn't ours to patch silently — it can change how the app behaves.
CustomHosted
- 3
Briefed as a change
Written up the same way any other change request is — this is what the Agentic iteration — CodeHerder add-on covers.
CustomLabs
- 4
An agent opens the pull request
The upgrade lands as a real pull request against the repository, with the test suite run against it.
CodeHerder
- 5
A human reviews and merges
Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.
CustomLabs
- 6
It ships through the same pipeline
The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit.
CustomHosted
- 7
You're told it's done
A note confirming what changed and that it merged, in the same shape as every other note on this site.
CustomHosted
Anything bigger than one pull request — a new consent architecture, or a rebuild of how the app handles personal data — is CustomLabs work, not a briefed change.
Said plainly
No compliance claim, no residency guarantee, and no promise to sign a data processing agreement — ask before you sign.
A backup outlives a delete
A row you delete from the live store still exists in every backup taken before the delete. It leaves only when that backup's own retention window rolls past it. Recovery
We publish no region list and no residency guarantee
This site runs from one region, in the United States. Ask which region a workload can sit in before you sign, not after — the honest answer may be that we are not the right host for your obligations.
We are not your data protection officer
We tell you how the platform behaves. We do not tell you what your own legal obligations are, and a data processing agreement is a contract conversation, not a page on this site — start it through the quote form. Get a quote
No certification to hand you
No SOC 2 report, no ISO 27001 certificate, no PCI scope. If your work needs one of these, you need to know that now. Under attack
Which jurisdictions we can offer for a customer workload, and whether we will sign a data processing agreement, are commercial questions, not a page on this site. Start that conversation through the quote form.
Your data, answered
The questions procurement asks first.
01Do you meet GDPR requirements?
We hold no certification and make no compliance claim. This page states, in writing, exactly how the platform handles personal data — read it and decide whether it meets your own obligations.
02Where does my data live?
This site runs from one region, in the United States. Ask which region a workload can sit in before you sign, not after — the honest answer may be that we are not the right host for your obligations.
03Will you sign a data processing agreement?
We tell you how the platform behaves. We do not tell you what your own legal obligations are, and a data processing agreement is a contract conversation, not a page on this site — start it through the quote form.
04I deleted a user. Why does support still see them in a backup?
A row you delete from the live store still exists in every backup taken before the delete. It leaves only when that backup's own retention window rolls past it. See Recovery for the full retention ladder.
05Who at CustomHosted can see my users' data?
The same principals Access already names, holding the same least-privilege rules — see § 04 above for what each one can and cannot reach.
06What happens if my users' data leaks?
The same escalation Incidents already runs — see § 08 above for the first hour, and Incidents for the note you receive.
Your data connects to
- Privacy
What we do with your enquiry — the quote-form data this page never covers.
- Security
The security questionnaire. It carries the delete and residency answers from this page.
- Access
The four principals and the capability matrix — this page reuses both whole for § 04.
- Recovery
Backups and restores as an operation — this page reuses its own retention ladder for § 05 and § 07.
- Logs
Log content and retention in full — this page names only the rows that hold personal data.
- Databases
The store § 03 names for a user account, an order, or a message.
- Files
The disk § 03 names for an upload or an export.
- Portability
Leaving, as a planned exit — this page reuses its pack list for § 07.
- Under attack
The perimeter, and the certification limit this page reuses whole in § 11.
- Outside services
The call to a third party this page names as a place personal data can go in § 06.
- Logins
This site's own login — there isn't one — the proof behind § 09.
Need a straight answer on where a workload's data would sit?
Ask through the same quote channel as any other request — a consent flow or a deletion endpoint is Agentic iteration — CodeHerder ($25/mo) work once you're a customer.