What the app is talking to.
Self-hosted software rarely works alone. It wants a mail server, an S3
bucket, a Google account to sign you in, a Stripe key, a website to check.
Handing you the app without those is handing you a screen full of connection
errors. So the whole surrounding world runs inside your session, and the app
is pointed at it instead of the internet.
Some of it is the real thing
Not an imitation — the actual protocol, running privately for you. Software
that works against these would work against a real server, and your history is
allowed to say so.
Mail
Cyrus with a real SMTP path in front of it. The app submits over SMTP, the message is actually delivered, and it is there to read. Nothing leaves the session.
You can open it: The mailbox.
Real
File storage
SeaweedFS, speaking real S3 including multipart upload. Apps that keep attachments, photos or backups work without an AWS account.
You can open it: The object browser.
Real
The web around the app
Pages that change between fetches, RSS and Atom feeds that gain items partway through your session, health endpoints that are up, down and deliberately flapping, a Prometheus endpoint with real numbers, and a valid OpenAPI document.
You can open it: All of it.
Real
A browser
Chromium with a screen, running as local processes inside your session. For apps that drive a browser themselves. No outside service is contacted.
Real
The rest are stand-ins
A vendor's API cannot be run privately, so these imitate one. Shaped like the
real thing and stocked with the same invented company — enough that the
sign-in completes and the calls answer. That is the whole claim: a demo
working here is not evidence the software works against the vendor, and your
record of the run says so rather than letting a green run imply it.
Vendor APIs
Fourteen of them, shaped like the real thing and stocked with the same invented company, so the sign-in dance completes and the API calls answer.
Stand-in
A model
An OpenAI- and Anthropic-shaped endpoint that replies, so an AI feature does something instead of erroring. It runs in your session like everything else.
Stand-in
The 14 vendors we answer for
GoogleMicrosoftAppleGitHubSlackOktaClerkStripeTwilioResendLinearVercelAWSMongoDB Atlas
One row per fixture, so Google covers the sign-in, the calendar and the
drive rather than appearing three times. Missing one you need? Ask for it.
All of it is stocked with the same company
An inbox with nothing in it teaches you nothing, so the fixtures do not start
empty. They are filled from one invented company, and the same people turn up
wherever they should — the customer in the invoice is the customer in the
mail thread.
Worldbusiness.saas-company v1
Scenarionormal operations
One world and one scenario today, pinned by the recipe so a demo is the
same one twice. Both are being written — a photo library needs somebody's
life in it, not a balance sheet.
Read about the company →
How the app finds them
It is told, not redirected
The recipe says which capabilities the app needs. At launch each one is
bound to the fixture running beside it, through the app's own
configuration — the same environment variables you would set yourself.
Nothing is intercepted and nothing is patched.
Nothing is shared
Every fixture is started for your session alone, inside the same private
machine, and destroyed with it. There is no shared mailbox and no shared
bucket.
Reaching out is recorded
Anything the app tries to reach beyond its session is written down from
outside the machine, so the software cannot edit its own record.
How that works →
Everyone in the data is invented. Every address ends in .droplive.test, a suffix that can never resolve, so none
of it can be mistaken for a real person or reach one.