One app. One container. One set of keys.
Your app runs in its own process, against its own database, with credentials that open nothing else. There is no route from another customer’s app to yours, and no setting where you could open one.
Isolation is not a feature here. It is the shape of the thing.
Shared hosting earned its reputation honestly. One machine, one web server, one database with a directory per customer, and a single mistake in any of it exposing everybody at once. Most of what people mean by “is hosting safe?” is a memory of that.
Nothing here is shared but the hardware. Your app is built into its own image and run as its own container, with its own filesystem and its own database, reachable with credentials that are useless anywhere else. There is no shared web root, no shared database server for customers, and no directory anybody can climb out of.
It applies to the free static site exactly as it applies to the app your business runs on, because it is not something we switch on per plan. It is the only way apps are run here.
No route between apps
One customer’s app has no network path to another’s, so a compromised app is a compromised app rather than a foothold. Nothing to enumerate and nothing to pivot into.
Your database is yours alone
Not a schema inside a shared instance. Its own database with its own credentials, attached to your app and nothing else, and destroyed with it when you delete it.
Every request re-checks who you are
In the control plane, every credential is bound to exactly one account and the membership behind it is verified on each request. Nothing is cached, so there is no window in which stale access still works.
The rest of the foundation.
No settings, and therefore no settings to get wrong. These are true of every app on every plan, without anybody asking for them.
Encrypted in transit, always
Traffic to us, to your app and between our own components runs over TLS. Certificates are issued and renewed automatically, on our hostname and on yours, so there is nothing to remember and nothing to let expire.
No password to steal
Nobody has one. You sign in with a code sent to your address, and every credential we store, including sign-in codes, sessions and API tokens, is kept only as a salted hash. A copy of our database opens no account.
Revoked is revoked immediately
Revoking an API token, an agent’s authorisation or an app invitation takes effect on the very next request rather than at the end of some window, because the check is made every time rather than cached.
Deletion actually deletes
Deleting an app removes its container, its volumes and its database rather than flagging a row. Closing an account starts a thirty-day clock, after which everything deployed goes with it.
Who can open your app is a question you answer, not one you code.
The lock sits in front of the app rather than inside it, so you do not have to build a login to have one, and a closed app is closed before your code is ever reached.
Open to everyone
The default, and the right one for a landing page or a site you want found. Nothing is in the way and search engines can read it.
Only the addresses you name
Invited people get a one-time code by email. No password for them to invent, a record of who has actually opened it, and removing one address changes nothing for the rest.
One shared password
For something rougher that you just want off the open web. A single field in front of the app, and you decide who gets the password. The two, compared →
Whichever lock you pick, the check happens before your app is reached, so a closed app cannot be crawled and there is nothing for a search engine to index.
A key you type to an agent is a key you have published.
This part is particular to hosting an agent drives, and it is the one thing here we would argue about with another host. The usual way a credential escapes is not a break-in. It is a live key sitting in a chat transcript, in a model’s context window, and inside a client we do not run. You cannot clear any of those afterwards, and you often cannot even find them.
So there is no tool here that accepts a secret. No environment parameter on the deploy tool, no way to write a value through the API your agent talks to. The omission is the design. An agent cannot leak what it was never able to hold.
What it can do is hand you a link. You type the value in yourself, the app restarts with it, and your agent goes back to work having never seen it.
Its own session, and a short one
The editor runs on a twenty-minute session of its own, separate from the thirty-day one that authorises your agent. Reading a live key asks for a proof from minutes ago, not from some point last month.
Masked until you ask for it
Values are hidden by default and revealed one row at a time. An unrevealed value is never sent to the browser at all, so it is not sitting in the page source either.
Your agent sees the harmless ones
Mark a variable readable and your agent can read it, which is what you want for a log level. Everything else it gets is a name and nothing more. The default is secret.
How the service itself is run.
The part you cannot see from the outside, written down so you do not have to take it on faith.
Changes go through review
Every change to agenthost lives in version control and is reviewed before it ships. Deploys are automated and reproducible, so a change can be traced back and reversed.
Your deploys roll back too
Every time you put something online it becomes a version, and the previous one is kept. Ask your agent to put it back and it will. Nothing you deploy is one-way.
Dependencies audited weekly
An audit runs every week and fails on a high or critical advisory. Dependency and platform updates arrive as scheduled pull requests rather than whenever somebody remembers.
Limits on the open doors
The handful of endpoints that need no credential are rate limited, including per email address rather than only per IP, so a flood of sign-in attempts is bounded whether or not it comes from one machine.
Every action is recorded
Every change to your account, every sign-in and every refusal is written to a log that can only be added to: who took it, from which agent or browser, from what address, and how it ended. The reads your agent makes are recorded too. It is kept for five years.
No secret reaches it, and nothing your app holds is copied into it. Server and application logs are a different thing, watched so faults and abuse are noticed rather than reported to us by you, and deleted after ninety days.
Few people, named access
Production access is limited to those who need it to run the service, granted individually and removed when it is not. Everyone with it is under a written duty of confidentiality that outlasts their engagement.
What we do not claim.
Every vendor page you have ever read is a list of things that are true. Here is the other list, because you will find it out eventually and it is better that you find it out now.
agenthost is in active development and is sold without a service level agreement. We do not hold an ISO 27001 or a SOC 2 certification, and we will not pretend otherwise on a questionnaire. Restoring from a backup is a best effort, so keep your own copy of anything you genuinely cannot afford to lose.
We also do not run a different contract per customer. There is one data processing agreement, published with a version and a date, already in force for everybody including the free plan. We would rather answer five specific questions well than fill in a three-hundred-row spreadsheet badly, and we will answer yours in writing within thirty days.
Everything above describes the system as it is today. When the system changes, this page changes with it.
Found something? Tell us.
It reaches the people who build agenthost, not a queue.
Write to support@agenthost.eu with what you found and enough detail to reproduce it. We will confirm we have it, tell you what we are doing about it, and let you know when it is fixed. There is no bug bounty and we cannot pay for reports, but we would far rather hear from you than not.
Two things we ask. Do not test against another customer’s app or account, and do not run anything that degrades the service for the people using it. Give us a fair chance to fix the thing before you publish it.
The questions that actually get asked.
Can another customer's app reach mine?
No. Each app runs in its own container with its own database and its own credentials, and there is no network route between them. In the control plane every credential is scoped to a single account and re-checked on every request, so there is no path from one account into another’s data either. It is the property we would least willingly give up.
Where does all of this physically run?
On servers in France, operated for us by a French company with no parent outside the EU. Your code, your files, your database and your backups are all there, and they stay there. The whole answer, in detail →
Is my data encrypted?
In transit, always, over TLS with certificates handled for you. At rest it sits on the storage of our infrastructure provider in France, and we do not add a second layer of application-level encryption on top of your database. If your app holds something that warrants that, encrypt it in your app, where you hold the key.
Do you look at what I deploy?
Only to run it for you. What you deploy is not mined, not profiled, not sold, and never used to train or evaluate a machine-learning model, ours or anybody else’s. Operators can read logs and containers when diagnosing a fault, which is a small number of people who need it to keep the service up.
Is my app's own security your problem?
Honestly, no, and you should know where the line is. We look after the platform: isolation, transport, credentials, the door in front of your app. What your code does with the data it collects is yours, and an agent will happily write an app with an authorisation bug in it. Read what it wrote, and put the sensitive things behind a lock rather than behind an unguessable URL.
Is there two-factor authentication?
There is no password, so there is no password to add a second factor to. Signing in means receiving a code at your address and typing it back, which means the strength of your agenthost account is the strength of your email account. Secure that one properly. Tokens for unattended clients are separate, listed, and revocable one at a time.
Can we see who did what on our account?
It is all recorded, and today you get it by asking us rather than by opening a page. Every change, every sign-in, every refusal and every admission to a private app is written down with the person, the agent, the address and the outcome, and kept for five years. Write to us and we will send you the record for your account. Reading it yourself is the part still to build, and we would rather say that than imply a screen exists.
What happens if there is a breach?
You hear from us at the address on the account within forty-eight hours of us becoming aware, with what we know at that point rather than a finished report weeks later. What we send and what we help you with afterwards is written down in section 11 of the agreement, not left to goodwill.
Can you complete our security questionnaire?
We answer specific written questions, within thirty days, from the people who actually build the thing. We do not fill in spreadsheets or sign customer addenda, because a term we could not really keep would be worth nothing to you. Most questionnaires are answered by the agreement and this page together, and you may audit us on the terms set out there.
What if my account is compromised?
Write to us and we will help. In the meantime, most credentials are revocable independently and immediately: API tokens one at a time, an agent’s authorisation on its own, an app invitation per address. Taking a person off the organization itself is the one that still goes through us rather than through a tool, so say so in the email and we will do it.
Put it somewhere you can point at.
Ten static sites free forever, no card, and a container of its own from the first minute. When you need to show somebody how it is run, send them this page.