How it works
What happens behind your app’s address.
From payment to a running, watched application, and what becomes of it if you stop paying. This page describes how the platform works today and says plainly what is not built yet.
Launch
From payment to a live address.
Nobody opens a ticket: the platform takes each step itself, and your dashboard shows where the app is.
-
Payment confirmed
The payment provider tells us the subscription is active. Your card goes to the provider; we never see it.
-
Deployed
The platform puts your application on our shared server in the EU and starts it in containers of its own, with its own configuration and freshly generated secrets, from an exact version we have pinned.
-
Checked
We request the app’s health address from the outside, the way a visitor would, and wait for a good answer. Only that answer turns “deploying” into “running”.
-
Live
The app answers at its own HTTPS address, and we email you the address.
If the check does not pass. When the app has not answered within the time allowed, the launch is marked failed and an operator is alerted. A launch nobody has seen answer is never reported as running.
Isolation
Your own stack, not a shared account.
Every application runs as a separate Docker Compose stack on a shared server.
-
Containers of its own
The application, and its database where it uses one, run in containers started for you alone. Other customers’ applications run in stacks of their own.
-
Data of its own
Files and databases live on volumes that belong to your stack. A database container sits on the stack’s private network and is not published on the server or the internet; the application’s own port is not published on the server’s public address.
-
Limits you pay for
Each stack is held to the CPU and memory limits of its plan.
Where the separation ends. Stacks of different customers share a machine and its kernel. This is container isolation, not a virtual machine each. A dedicated server is on the roadmap.
Address and HTTPS
Its own address, secured from the first request.
Where the app runs, what it is called, and how traffic reaches it.
-
In the EU
Servers run in Frankfurt (AWS Lightsail, eu-central-1), and every application runs there today. Choosing another region is on the roadmap.
-
A subdomain of its own
The app answers at an address of the form name.poof.run, picked when you buy, with no DNS for you to set up. It can also answer at your own domain.
-
HTTPS only
One wildcard certificate from Let’s Encrypt covers every address on the server and renews itself. Plain HTTP is only ever answered with a redirect to HTTPS, and the proxy is the only public way to the application.
Monitoring
Watched, so you do not have to.
Two kinds of checks run around the clock: on every application and on every server.
-
The app is asked
Every few minutes the platform requests the application’s health address from the outside, as a visitor would. A bad answer, a timeout or a dropped connection counts as a miss. A run of misses, not a single one (which is normal during an update), opens an incident and emails our operators, and they are emailed again when it recovers.
-
The machine is measured
Each server’s state, CPU, memory, disk and burst capacity are measured every few minutes. Low free disk, exhausted burst capacity or a failed provider check opens an incident.
-
Containers restart themselves
A container that crashes is started again, and comes back after a server reboot, unless we stopped it on purpose.
What this is. Alerts go to our operators, not to you, and the checks show that the app answers, not what is inside it.
Updates
Versions we choose, changes we make.
You install and patch nothing. Updates are not silent either: this is how they work.
-
Exact versions
An application runs one exact image version, not a moving tag such as “latest”, so what runs is what we prepared.
-
Rolled out by us
A new version reaches your app when an operator starts the upgrade, from the version you run to the one that follows it. The application is restarted onto it, so expect a short interruption.
-
One way only
There is no rollback. An upgrade can change the application’s database in ways that cannot be undone, and we do not make backups yet, so there is nothing to go back to.
Billing and lifecycle
Paying, stopping and what stays.
What happens to a running app follows its subscription, and nothing is deleted without warning.
-
A payment fails
The app keeps running while the payment provider retries the charge. You get an email asking you to update your payment method, and a reminder while it lasts.
-
The subscription ends
When it is cancelled, or the retries run out, the app is stopped (stopped, not deleted) and we email you. A cancellation set for the end of the period keeps the app running until then.
-
Kept for 30 days
Its data stays on the server for 30 days from the moment it stops. To bring it back in that time, write to us — the data is still there. We email you 7 days before the end.
-
Then deleted
A final window of 24 hours follows, with a last email; until it ends, writing to us still brings the app back. After it, the app, its data volumes and its files are destroyed, and that cannot be undone.
No backup behind this. Deleted means gone: we keep no copy to restore from, which is what the reminders are for.