YOUR APP. YOUR DATA. YOUR CHOICE.
Your data is portable. The platform is what you pay for.
For customers asking what happens to my app and data if ERP.AI isn’t in the picture. Short answer: your data is portable by design, your schema is open, and a code export is available as a contracted capability. The longer answer, security, operations, compliance, and what an export actually contains, is what this page is about.
The
Shape
Of The
Repo
.
A conventional codebase when a code export is scoped.
Readable, reviewable, forkable. No engine binary. No callback home.
# Export your tenant as a standalone repo
erpai export --target react-postgres --out ./my-app
# What you get
my-app/
├── apps/web # React + TypeScript
├── apps/api # Node + Postgres
├── migrations/ # plain SQL DDL
├── auth/ # Supabase / Auth0 / Clerk adapter
└── README.mdWhere's My Data · Auth · App
Your Database
Postgres. Supabase-compatible schema. Tables, columns, constraints, row-level security, all plain SQL, checked into /migrations. Point the exported app at any Postgres you want: Supabase, RDS, Cloud SQL, self-hosted, on-prem. Your data never lived in a proprietary store. It lived in Postgres the whole time. What changes after export: backups, snapshots, disaster recovery, encryption-at-rest, point-in-time restore, failover, and data residency compliance all become your team’s responsibility rather than ours.
psql $DATABASE_URL < migrations/0001_init.sql
Your Authentication
Pluggable at export time. The auth layer is a thin adapter, swap between Supabase Auth, Auth0, Clerk, Cognito, Okta, Entra ID, or your existing SSO by replacing one module. Identity lives in your IdP. Always did. The default target is Supabase Auth because it maps cleanly to RLS, but nothing is hard-wired. What the engine handled silently, now yours to own: token rotation cadence, session hijack detection, MFA enforcement, brute-force protection, SSO claim mapping, CSRF tokens, OAuth refresh flows, and the hundred small hardening choices that separate a login form from an authentication system.
auth/provider = supabase | auth0 | clerk | okta
Your Hosting
Two supported paths. Deploy one-click on build.host: bring your own Postgres, your own auth, your own domain; we operate the box and you own the stack. Or pull it into your own repo and run it anywhere: Vercel + Supabase, Docker + RDS, on-prem Kubernetes. It's a normal repo. No special runtime required. Self-hosted means self-uptime too: autoscaling, queue workers, cache invalidation, log aggregation, alerting, pager rotations, incident response, regional failover, CDN config, DDoS absorption, and a 24/7 on-call your business didn’t need when we ran the box.
deploy → build.host · vercel · fly · docker · k8s
Deploy
Anywhere
You Want
.
A conventional React + Node repo. If your team already ships Node/Postgres apps, they already know how to ship this one.
# One-click deploy. Bring your own:
# · Postgres (Supabase, RDS, etc.)
# · Auth provider (Auth0, Clerk, ...)
# · Domain
build.host deploy ./my-app
→ https://acme.build.host# Frontend → Vercel. Database → Supabase.
# Auth → Supabase Auth (default adapter).
git push vercel main
supabase db push ./migrations
→ https://acme.vercel.app# Postgres on RDS. API on ECS Fargate.
# Static frontend on S3 + CloudFront.
# Auth via Cognito or Okta.
aws ecs update-service \
--service my-app-api \
--force-new-deploymentservices:
web: { image: my-app/web, ports: ["3000:3000"] }
api: { image: my-app/api, ports: ["8080:8080"] }
postgres: { image: postgres:16, volumes: [pg:/data] }
docker compose up -d
→ http://localhost:3000# Your cluster. Your air gap. Your rules.
# Auth behind your SSO (Entra, Okta, Keycloak).
kubectl apply -f ./deploy/
helm install my-app ./chart
→ https://erp.internal.corp# Clone. Push. Review. Ship.
git remote add origin [email protected]:acme/erp.git
git push -u origin main
# Your CI, your review process, your rules.
# ERP.AI is no longer in the critical path.
Proto
Moves
The Data
.
Exporting isn’t a big-bang migration.
It’s a continuous capability you already have.
Proto, the agent runtime underneath ERP.AI, can stand up the pipelines that stream your data out of the engine and into anywhere you want it. Your warehouse, your lake, your replica, your regulator’s evidence bucket. You describe the destination; Proto builds the flow.
-
01One-shot batch exportPoint-in-time snapshot delivered to S3, GCS, Azure Blob, or any SFTP target. Parquet, JSON, CSV, or pg_dump. The format your team already ingests.
-
02Continuous mirrorChange-data-capture into a Postgres replica you control. Your read-models, your reporting, your disaster-recovery, fed live, while the engine keeps running.
-
03Warehouse streamingRows flow into Snowflake, BigQuery, Redshift, Databricks, ClickHouse, whichever stack your analytics team uses. Schema drift handled; you see columns, not JSON blobs.
-
04Scheduled compliance dumpsSigned, timestamped snapshots to your evidence bucket on the cadence your auditors require. Retention policy and hash chain preserved.
-
05Full migration when it’s timeAcquisition, divestiture, regulator-driven self-hosting, whatever the reason, the combination of an exported repo and Proto pipelines gets you to a running, owned stack. We’ll scope the work with your team.
Security
Is The Part
Nobody
Screenshots
.
Running your own app security is hard.
Running your own AI security is harder.
Both at once, in production, at speed, is where most self-hosts quietly fail.
An exported repo is a snapshot. Security isn’t. Attack techniques, patched CVEs, model jailbreaks, prompt-injection vectors, data-exfiltration patterns, OAuth edge cases, token-leak primitives, the threat landscape moves every week. When you run on the engine, three things absorb that movement for you: a dedicated security team, a graph-based authorization model, and an internal research program studying graph neural networks for exactly this class of problem. When you export, that movement stops being absorbed. It starts arriving at your team.
The engine is, in a meaningful sense, a living security perimeter. ERP.AI’s authorization model doesn’t operate as “do what the user typed.” It operates over your permission graph. Every action, query, or tool call is resolved against what that specific identity is allowed to touch. A prompt-injected instruction to “export all invoices” doesn’t succeed because the AI “decided not to.” It fails because the graph edges aren’t there.
Our internal GNN research program is how we keep tightening those bounds: learning edge-importance scores over authorization graphs, detecting anomalous traversals before they complete, and hardening the system against the next class of attack rather than the last one. Reproducing this in an exported codebase is possible. It is not cheap. And it is not a one-time project.
Graph-Bounded AI
Every AI action resolves against your identity’s permission graph before execution. Prompts can’t escalate privileges, because privileges aren’t text. They’re graph edges. Active GNN research continuously sharpens how tightly those edges are drawn. Self-host this and you rebuild it yourself, per feature, per endpoint, without the research backing it.
Prompt-Injection Hardening
Content fetched from records, attachments, or external sources is quarantined before it reaches a model. Your exported stack inherits none of this. Hardening against indirect prompt injection in customer data is a research problem your team now owns.
Data-Exfiltration Bounds
Tool outputs, log streams, and model context are scoped at the graph layer so an agent can’t “summarise” its way around RLS. After export, preventing model responses from leaking data the user doesn’t normally see is on you.
Continuous Patch Cadence
Every week, new CVEs land across the Node, React, Postgres, and LLM ecosystems. On the engine, mitigations reach your tenant without you noticing. On an exported repo, mitigations reach you when your team has time to read release notes, which is rarely the same week.
Audit & Compliance Posture
Tamper-evident audit trails, per-record access logs, retention policies, right-to-be-forgotten workflows, and the evidence your auditors ask for all live inside the engine. After export, recreating this for SOC 2, ISO 27001, HIPAA, or GDPR is a programme of work, not a config change.
A Dedicated Security Team
The engine is defended by people whose job title is “defend the engine.” They run red-team exercises, triage advisories, wake up when something’s burning, and work alongside an in-house GNN research program dedicated to hardening graph-based authorization against new jailbreak classes. Hiring and retaining an equivalent team internally is many line-items you currently don’t pay.
A code export delivers the repo. The platform delivers the sleep. Most teams underestimate the second until they have to staff it themselves.
What We Tell Customers Weighing A Code Export
Your data is a right. The code is a capability of the platform we operate.
The Ownership Principle
Why The Engine Still Earns Its Place
An ERP.AI subscription is a subscription to work done continuously on your behalf. Four specific categories of work:
- GNN-backed security. A permission-graph authorisation model, prompt-injection quarantine, data-exfiltration bounds, and an active graph neural network research programme that tightens those bounds as new attack classes emerge.
- Cloud that meets the SLA. Enterprise-grade uptime, patched continuously, defended by a named security team, with the incident response and audit evidence compliance teams already require.
- The platform itself. A compiler from structured intent to running app. Proto for agentic workflows and data movement. The composition engine that lets a schema change propagate through UI, API, permissions, and agents in seconds instead of sprints.
- An AI that maintains your code. Models improve; your app improves with them. New integration patterns, better ergonomics, fresher frameworks. Absorbed into the running system rather than queued as upgrade work for your team.
Your data is portable by design, schema open, format standard, movement handled by Proto. That part is a right. The compiled code is the platform’s craft, and a code export is a contracted capability: real, available, and scoped with your account team when the situation calls for it. Acquisitions, divestitures, regulatory self-hosting mandates, strategic decisions to in-house entirely. Those are the moments a code export earns its keep, and we execute them cleanly on the terms in your contract.
The pattern is consistent across every customer that has examined this seriously: the subscription is held because the four categories of work above are hard to replicate in-house, expensive to replicate at speed, and impossible to replicate as continuously. Stay for the platform. Keep the data portable. Negotiate the code export as the commercial event it is. That is the recommendation we stand behind for the overwhelming majority of deployments.
Trade-Offs You Should Know
You're On A Fork
The moment you export, your repo is frozen in time. New ERP.AI capabilities, model upgrades, richer workflows, improved agents, don't land in your codebase automatically. You maintain it from there.
Conversation-Speed Iteration Ends
The "just tell me what to change" experience is what the engine provides. After export, changes happen in code: pull requests, review, deploy. Powerful, but no longer editable by prompt.
Automations Translate, Not Copy
Workflows and agent actions convert into conventional backend handlers your team can read and modify. That's the whole point. But it means you're now maintaining orchestration code that the engine handled for you.
You Own The Ops Burden
Uptime, patching, backups, scaling, security updates, dependency bumps, all yours. On build.host we run the box for you; elsewhere, your ops team inherits the full stack. Budget for that before you export.
Insurance, Not Daily Target
Most customers stay for the platform and keep the data portability as an absolute right. A code export is scoped when the situation calls for it, acquisition, divestiture, regulatory mandate, and delivered under the commercial terms in your contract.
When Export Is The Right Call
Compliance reviews, security audits, acquisition due diligence, a divestiture that forces a new stack, a strategic decision to in-house the app entirely. For those moments, the export is ready. For everything else, stay on the engine.
The platform earns its place because the four things it does, GNN-secured AI, cloud-scale operations, structured-intent compilation, and continuous AI-maintained code, are demonstrably harder, slower, and more expensive to replicate in-house. Your data stays portable. The rest is what the subscription is for.
Postgres keeps your app running. The platform keeps it improving.
Your subscription to ERP.AI is a subscription to four things at once: a GNN-backed security model that hardens AI actions against the attack classes that keep CISOs awake; a cloud operated to enterprise uptime standards, with the security team, patch cadence, and incident response that go with it; a platform that compiles your app from structured intent rather than hand-written code; and an AI that continuously maintains that app, absorbing schema changes, upgrading integrations, adopting new patterns, and shipping improvements as the model and the platform evolve. Your data is yours, exportable by design. The rest is the work the platform does on your behalf, for as long as it is on your behalf.
Questions about export, data movement, security, or compliance? Talk to your account team.