Skip to content

Where to host worker-built apps

Host a worker-built app by its risk tier. A Sandbox app stays in its builder tool's private workspace, and a tool that can't keep it private isn't approved for Sandbox.

Team and Important apps run on one of three approved patterns: your low-code tenant, a company-managed AI app builder workspace under company sign-in with a deny-by-default database, or an internal hosting platform behind a sign-in proxy. Critical apps go on IT's standard platform.

Never host a shared app on a personal account or a public-by-default service. As of October 2026.

Who this is for

Infrastructure and platform leads and IT managers who have to say where employee-built apps may run. You get a decision table, four reference architectures, a view on AI gateways and a short note on data location. About 10 minutes.

Every worker-built app sits in one of four risk tiers (Sandbox, Team, Important or Critical), set by the highest answer to six questions about its data, users, internet reach, dependence, decisions about people and actions, and two floors apply at every tier. The six tier questions and the deploy gates live on the risk tiers page. This page covers only where the app runs.

Which hosting pattern fits which tier?

Pick the pattern from the tier first, then check the data classes the tool is approved for on the approved tools list.

Fast-moving

As of October 2026. Builder platforms change sharing defaults, licence tiers and data regions often. Recheck what each pattern can enforce at the licence you buy. Check the review date.

Pattern Tiers Strengths Weaknesses Exit
Private workspace in an approved builder tool Sandbox No setup; private by default where the tool supports it Time-boxed; nothing shared Delete or register at a higher tier
A. Low-code tenant Team, Important Tenant controls, connector rules and data-loss rules built in; company sign-in already there Less flexible; logic is locked to the vendor Export data; rebuild the logic
B. AI app builder plus managed backend Team, Important Real code, fast; deny-by-default data rules available Public-by-default history; keys in the browser; the platform itself can fail Export code to a repository you own; export data
C. Internal static or container hosting behind a sign-in proxy Team, Important Portable; full control of access; fits a platform team Someone has to run and patch it Move the container or files
IT's standard platform Critical Monitoring, on-call and change control come with it Slowest to start; needs co-ownership Platform-defined

The tool's approved data classes cap the pattern: an app can't hold data above the classes its tool is approved for. Download the table as a spreadsheet: hosting-decision-table.csv. Prompt to Prototype, Where to host internal AI-built apps, https://prompt-to-prototype.com/platform/hosting/, as of October 2026. Licensed CC BY-SA 4.0. Using or adapting it inside your business isn't distribution under the licence.

Pattern D (an app with an AI feature calling a model) isn't a place to host. It's an addition to A, B or C, described below.

Patterns A and B need nothing beyond bought services and admin settings, so they're the default when you have no platform team. Price them at the plan you need, though. Pattern B's company sign-in and sharing controls are often on a top plan, and its managed backend may be a second contract with a second vendor, so budget for both. Pattern C needs someone to run the proxy and the hosting account, so treat it as the variant for businesses that already run a platform team (C6). The paved road lists what to buy.

Depends on your circumstances (C6)

If you already run a platform team or pipelines, pattern C gives you the most control and the easiest exit. If you don't, don't build it for this.

Don't: host on personal accounts or public-by-default services (AP1)

Public-by-default data stores and portals are the most repeated documented exposure, from Power Apps portals to open Firebase rules to AI-built apps.1 A shared app on a personal account also breaks the third of the five never-dos, and it leaves with the builder. The five never-dos are defined once on the build page.

What do the reference architectures look like?

Each sketch shows the path a request takes and where access is checked. If a box in your design has no check, that's the gap.

A. Low-code tenant. Users sign in through your identity provider. The platform enforces sharing limits and connector policy. Data stays in the platform's store or flows through approved connectors only.

flowchart LR
  U[Staff] --> IDP[Company sign-in]
  IDP --> T[Low-code tenant]
  T --> CP{Connector policy}
  CP --> D[(Platform data or approved connectors)]

B. AI app builder plus managed backend. The builder's workspace is company-managed and signed in. The backend denies access unless a row-level rule allows it, and the app holds no keys in the browser. The backend's data API is on the internet, and the company sign-in in front of the app doesn't protect it. Anyone with the public key can call it directly, so the row-level rules and a negative access test (query it signed out and as a second user) are what keep it private. The exposed data page explains the exposure and gives the test. Run its exposure scan on Team apps too, as good practice.

flowchart LR
  U[Staff] --> IDP[Company sign-in]
  IDP --> B[App from AI builder]
  B -->|signed-in user token| RLS{Row-level rules, deny by default}
  X[Anyone on the internet with the public key] --> RLS
  RLS --> DB[(Managed database)]
  B -. server-side only .-> S[Secret store]

The secret store has to meet the four conditions in the downgrade path: never sent to the browser, admin-only access, rotatable without a code change, and its location named in the app record.

C. Internal hosting behind a sign-in proxy. The proxy checks the company identity before any request reaches the app. Examples of the capability: Cloudflare Access, or Google Cloud Identity-Aware Proxy. The app has no public address of its own.

flowchart LR
  U[Staff] --> P[Sign-in proxy]
  P --> A[Static files or container]
  A --> DB[(Database, private network)]
  A -. runtime injection .-> S[Secret store]

D. App with an AI feature. Calls to the model go through one layer that holds the provider key, logs usage, applies data-loss rules and caps spend. The layer can be your provider's organization controls or a gateway. The key never sits in the app.

flowchart LR
  A[App] --> M[Model-access layer]
  M --> L[(Usage log)]
  M --> C{Caps and data-loss rules}
  C --> P[Model provider]

Check the trifecta rule too: the feature must not combine private data, untrusted content and a way to send data out (AI features).

Public-facing apps break the default. Floor 2 says no internet reach without company sign-in below Important, so a public app is allowed only at Important or Critical, on a pattern you've approved for it, with an exposure scan on a schedule. Every Important app gets the monthly exposure scan, public or not. Don't improvise a public pattern per app.

Hypothesis to test

We expect that A, B and C cover most worker-built apps (A-039). Test it in your pilot: count the intake requests that fit none of the three. If they're more than a small share, the problem is the patterns, not the builders.

Do you need an AI gateway?

An AI gateway (a model-access layer) is one place for provider keys, usage logs, data-loss checks, spend caps and switching models. As of October 2026 we searched and found no independent data on how widely businesses use gateways, so don't assume your peers all have one.

Start with the cheaper option: your model provider's organization controls (a key per project, spend limits, usage exports). Add a gateway when you use several providers, need central data-loss checks across apps, or need per-app cost attribution the provider can't give you. Examples of the capability are an open-source proxy such as LiteLLM, a gateway service from a cloud provider, or one from an API-management vendor; check them against your needs. Control AI spend covers caps and alerts, and AI features covers what an app with a model call must pass before launch.

Don't: buy a gateway before you know you need one

A gateway is one more system to run, patch and secure, and it holds your provider keys. On 24 March 2026 two versions of a widely used open-source gateway package (LiteLLM 1.82.7 and 1.82.8) were published to PyPI with a credential stealer after a maintainer account was compromised.2 If you have one provider and a handful of apps, provider controls are enough. Revisit when the second provider or the tenth AI feature arrives.

How do you separate test from production?

Team apps should try changes away from live data. Important and Critical apps need separate test and production environments with different credentials and access. The reason is documented: a coding agent working on a live database can delete it despite instructions not to (failure pattern AP4).3 Keep agent and builder credentials in test, give production credentials only to the app's runtime, and keep backups the agent can't reach (AP4).

Don't: use one environment as production

A builder who edits the only copy edits live data. Even a one-line fix needs somewhere to fail safely. Backups only count after a restore has been tested.

Where may the data live?

Not legal advice

Not legal advice. This page summarizes laws as of October 2026 for a general audience. It was written with an AI legal-research persona and hasn't been reviewed by a lawyer for your situation. Ask your counsel.

Where an app's data is stored or processed is a preference for most apps and a requirement for some. Treat it as a requirement when one of these applies, in this order:

  1. Contracts and customer commitments. A customer contract, security questionnaire or public promise may name a country or region. This is the most common source, and it's yours to read before the law is.
  2. Sector rules. A health plan or provider, or a vendor handling health data for one, needs business associate terms with its vendors.10 HIPAA itself sets no country for storage; HHS says a cloud provider may store ePHI outside the US under a business associate agreement, with the location weighed in the risk analysis.4 Some states add a storage rule of their own: Texas requires electronic health records to be physically kept in the US or a US territory, including in cloud services (from 1 January 2026),5 and Florida requires licensed providers' offsite patient data to stay in the continental US, its territories or Canada.6 An offshore model provider or sub-processor can break those rules even when the builder is US-hosted. Financial institutions must oversee their service providers under the GLBA Safeguards Rule.7
  3. Quebec. If you carry on business in Quebec, Law 25 requires an assessment before personal information is communicated outside Quebec, including to a service provider, and a written agreement.11 That catches a US-hosted AI builder holding Quebec personal data. Quebec public bodies have a parallel rule in their own access act. Elsewhere in Canada, PIPEDA sets no location rule but keeps you accountable for data a processor holds abroad.
  4. Public-sector rules. As of October 2026, Nova Scotia's PIIDPA (s. 5) requires public bodies and their service providers to store and access personal information only in Canada, unless the individual consents, the disclosure is otherwise allowed, or the head of the public body permits it.8 A vendor selling to a Nova Scotia public body is bound itself. British Columbia repealed its equivalent rule (FIPPA s. 30.1) in 2021; s. 33.1 now lets a public body disclose outside Canada only as the regulations allow.9 Other provinces and public bodies differ and keep changing, so ask counsel if you serve a public body (C2).
  5. EU personal data. GDPR transfer rules apply only if the GDPR applies to the data (EU-US data transfers). As of October 2026 the EU-US Data Privacy Framework is in force, and an appeal against it is pending.

Location isn't the same as access. A US rule also restricts bulk sensitive data reaching countries of concern, including through vendor access (US and Canadian laws). A vendor that stores data in your region can still let staff or sub-processors elsewhere read it, so ask for both on the contract-terms table (the data location row). Record the region in the app record, and set it per tool when you approve it. If your data crosses borders routinely (C3), see data handling and US and Canadian laws.

How do you keep an exit open?

Pick patterns by how you'd leave them. Pattern A is the hardest to leave, because the logic lives in the vendor's format. Pattern B depends on whether the builder exports code to a repository you own. Pattern C is the easiest.

Vendors do fail or change, and dated examples include an AI app-development company that entered insolvency in May 2025.12 Plan for a vendor that disappears. The approval page says what an exit plan contains. For each pattern, test the export before you rely on it, and keep a second approved option for apps that matter.

How do you record the hosting decision?

Record the approved patterns once, with the decision record template.

Illustrative composite

Title: Approve hosting patterns A, B and C · Status: accepted · Date: YYYY-MM-DD · Owner: IT infrastructure lead (a role)

Context. Staff build apps with AI tools. We have a low-code tenant, one approved AI app builder and no platform team.

Decision. Sandbox apps stay in approved tools' private workspaces. Team and Important apps use A or B. Critical apps go to IT's standard platform. Every Important app gets the monthly exposure scan; public-facing apps only at Important or Critical. AI features go through provider organization controls; we revisit a gateway if we add a second provider.

Alternatives considered. Pattern C (rejected: nobody to run it). One pattern only (rejected: the tenant can't host code-based apps). Gateway now (rejected: one provider).

Consequences. Apps that fit none of the patterns need an exception from IT. We review at six months.

Questions to ask your counsel

  1. Do any customer contracts, sector rules, state health-data storage laws or public-body rules restrict where this app's data may be stored or processed?
  2. Which of our apps hold Quebec personal information, and do we have the assessment and agreement before it leaves the province?
  3. Do our health-data vendors have business associate terms that cover the regions where they host?
  4. If an app serves a public body, what location or access rules come with that contract?

Assumptions and evidence

  • A-025 (Medium): the platform itself can fail, so an approved platform isn't a safe one; test this by reading each builder's incident history before approving it.
  • A-039 (Low): we expect a few approved patterns to cover most apps; test this by counting intake requests that fit none.

Evidence: documented exposures and vendor post-mortems; no independent adoption data for gateways, and none for hosting-pattern outcomes. The location note rests on statutes and the research file, not on a lawyer's review. Facts on this page are as of October 2026.

  1. Failure patterns AP1 and AP4, with the incidents behind them, are on failure patterns. [primary] Accessed 2026-10-22. ↩

  2. GitLab Advisory Database, GHSA-5mg7-485q-xm76, litellm, 24 March 2026; malicious versions 1.82.7 and 1.82.8 on PyPI, since removed. [primary] Accessed 2026-10-22. ↩

  3. Failure pattern AP4, with the July 2025 incident (a coding agent deleted a production database despite instructions) and its sources, is on failure patterns. [primary] Accessed 2026-10-22. ↩

  4. HHS Office for Civil Rights, Guidance on HIPAA and cloud computing. [primary] The page blocked automated fetches; read it before relying on this summary. Accessed 2026-10-22. ↩

  5. Texas Legislature, Health and Safety Code ch. 183, as amended by SB 1188 (2025); the storage rule applies to records stored on or after 1 January 2026. [statute] The chapter page didn't load for us, so the wording comes from published summaries of the bill; read the section before relying on it. Accessed 2026-10-22. ↩

  6. Florida Legislature, Fla. Stat. s. 408.051(3): patient information stored offsite, including with third parties or cloud services, is "physically maintained in the continental United States or its territories or Canada". [statute] Accessed 2026-10-22. ↩

  7. Cornell Law School, 16 CFR §314.4, (f), overseeing service providers under the FTC Safeguards Rule. [statute] Accessed 2026-10-22. ↩

  8. Nova Scotia, Personal Information International Disclosure Protection Act, SNS 2006, c 3, s. 5 (storage and access only in Canada; applies to a public body and to a service provider or its associate). [statute] The wording of s. 5 was read through search results, not the statute page. Accessed 2026-10-22. ↩

  9. British Columbia, Freedom of Information and Protection of Privacy Act, RSBC 1996, c 165, s. 33.1 (disclosure outside Canada only as the regulations allow); ss. 30.1 to 30.2 repealed by 2021-39-17. [statute] Accessed 2026-10-22. ↩

  10. Cornell Law School, 45 CFR §164.504(e), business associate contracts. [statute] Accessed 2026-10-22. ↩

  11. Québec, Act respecting the protection of personal information in the private sector, CQLR c. P-39.1, s. 17 (communication outside Quebec) and s. 18.3 (written agreement with a service provider). [statute] The site blocks automated fetches; the text was checked in the legal research file. Accessed 2026-10-22. ↩

  12. MLQ.ai, Builder.ai files for bankruptcy as insolvency declared, May 2025. [news] It confirms the insolvency only, not what customers lost; the sentence above is limited to that. Accessed 2026-10-22. ↩