What is separated from what, and where the keys are

The boundary is per application and per environment, not per customer. An application's test copy and its live copy do not share a database, a cache or a storage bucket, and neither of them shares one with any other application.

That is how every application starts, and it is what makes a version safe to test. A workspace owner can give part of it up deliberately — one database behind an application's three environments, or one shared by two applications that are about the same customers — and nothing else moves with it: the cache, the storage bucket, the network and the container stay separate either way. Where it has been given up, every screen that shows an environment says so.

Concretely, each application gets:

• its own bridge network;
• its own cache, and its own database unless an owner has deliberately pointed it at a shared one;
• its own storage bucket, reached with a service account whose policy names that one bucket — so although one object store serves every application, none of them can read another's files;
• a container with only that application's files mounted, no access to the host's container runtime, and no platform credentials in it.

The names the platform sets itself — the database address, the storage credentials, the platform token — are reserved and cannot be overridden by an application's own configuration, because overriding one would be reaching for another tenant's database.

We treat storage isolation as something to verify rather than assume: a policy that fails open looks exactly like one that works, so it is tested against a real server rather than asserted.

An application holds no third-party credential. It does not have your email provider's key or your Google account. It asks the platform to send an email, and the platform does it with whatever your workspace configured. What the application holds is a token that asks for a capability, not the key behind it — and that token is revocable without touching the application.

Google is connected per application, so a client-facing application and an internal one can use different accounts and revoking one leaves the others working.

Values you put in Settings are encrypted at rest. A secret is write-only: once saved it can be replaced but never read back, and the screen shows a hint rather than the value. A settings page that hands back everybody's API keys is a worse leak than the one it prevents.

The builder is told the names of your configuration values so it can write code against them, and never the values. A value in the prompt is a value in the transcript.

Whether an application is open, behind one shared password, or requires accounts is enforced in the proxy, in front of it. Every request is checked before any of it reaches the container.

That placement buys four things worth stating separately:

• it covers every page, every API route and every published file, including ones a later build adds;
• it holds while the application is mid-deployment, or while its build is broken;
• the application cannot turn it off by accident, because it is not the application's to turn off;
• a request being checked is never replayed — the check is a separate request, and the real method and address travel as headers.

The shared-password cookie is derived, not stored: it is a signature over the application, the environment and the current password. Two consequences follow. Changing the password ends every session opened with the old one, with nothing to expire and no list to clear — which is exactly what you press when a password has got out. And the test and live copies are separate doors: a client shown the test copy has not been shown the live one.

An application's raw container port is bound to the loopback interface, not to every interface, so there is no second front door that goes around the proxy — and with it around the password gate, the routing and the search-engine rules.

Platform sessions are opaque tokens held server-side behind an httpOnly cookie. Not a self-contained token, deliberately: revoking a session is a single delete that takes effect on the next request, rather than waiting for something to expire. Suspending a workspace or banning an account signs everyone concerned out immediately.

A session is bound to one workspace. An account can belong to several, and the role is resolved from that pairing on every request — so a role taken away applies from the next one, not at the end of somebody's week. Switching workspaces ends the session and starts another; removing somebody from a workspace signs them out of that one and leaves any other they are in untouched.

The people who sign in to your application are your customers, not our users. They are stored apart, cannot reach the workbench, and a session belongs to the one application it was made for. Your business adds, renames, resets and suspends them itself.

A generated application stores no password hash and writes no session logic of its own — it renders its own sign-in screens and asks the platform. Two-step sign-in is each person's own choice: email codes and authenticator apps today. An authenticator is not enrolled until a code from it is confirmed, so nobody locks themselves out of an application they never finished setting up. Codes are hashed, work once, and are limited to a few attempts.

A password reset generates a password, shows it once, and signs that person out everywhere — which is usually the reason somebody is on that screen.

The builder acts as the person who asked it. A run carries the identity of whoever sent the message, and their role is resolved and enforced in the same code the buttons go through. A viewer cannot deploy by asking the builder nicely. An automated run with nobody behind it gets no platform permissions at all, rather than acting with nobody's authority.

Deploying records the reason in the words of the person who ordered it, so a release nobody remembers ordering traces back to the sentence that ordered it.

What an application stores is in that application's own database, which nothing else reaches. What its users upload is in that application's own bucket.

The source is yours. A workspace owner can export the full repository, with its history, at any time. There is no format to convert out of and no proprietary runtime to leave behind — it is a Nuxt application that runs on an ordinary machine.

Conversations, builds and versions are retained so that a version can be gone back to and a release can be accounted for. If your retention policy requires something different from ours, that is a conversation to have before you start rather than after.

Page views for deployed applications are counted without identifying anybody. A visitor is a one-way hash of address and browser, salted with a secret and with the day, which means it cannot be reversed into an address and does not carry from one day to the next or from one application to another.

No identifier is stored, no cookie is set for counting, and nothing is shared with a third party. Reports are signed, so nothing on the public internet can inflate the numbers, and a failure to count is silent — a visitor's page must never break because analytics was slow.

What this website itself collects is a shorter list again.

Nothing reaches your users because a build finished. A build changes the preview, which only your team can reach. Moving a version to test, and a tested version to live, are separate acts by a named person.

A deployment builds the version first and only moves the address once the new server answers, so a version that does not build cannot replace the one that is live. Every build is retained as a version, whether it succeeded or failed, so going back is always possible and is not conditional on somebody having thought to save.

Redirects, search-engine rules and published files are served in front of the application, so they keep working while it is broken, mid-deploy, or has never been deployed at all — which is exactly when somebody needs an old address to still resolve.

We do not claim certifications we do not hold, and you will not find a badge on this page. What we will do is answer your review directly: send us the questionnaire, the architecture questions, or the specific controls your policy requires, and you will get answers from somebody who has read the code rather than a filled-in template.

Data-processing terms, hosting arrangements, sub-processors, retention and deletion are settled in writing as part of setting a customer up — which is one reason this is not sold self-serve.

Where a deployment model matters to you — where the platform runs, who operates it, what leaves your network — say so early. It changes the shape of the engagement rather than being a setting to toggle afterwards.

If you believe you have found a vulnerability in the platform or in an application it generated, write to hello@desifex.com with enough detail to reproduce it. We will confirm receipt, tell you what we have found, and tell you when it is fixed.

Please do not run automated scans against a customer's deployed application, and please do not access, modify or retain anybody else's data while demonstrating something. We will not pursue anyone who reports in good faith and stays inside those two lines.