# What every OpenCloud app runs on

Every app gets a database, server code, background jobs, schedules, file storage, sign-in, email and connections to the tools you already use. The Agent builds and tests it in a private preview. OpenCloud runs it, backs it up and keeps watch.

- Private by default
- Tested before it goes live
- Undo for code and data
- Cloud hosted in London, UK

Everything on this page is available today. Updated 18 October 2026.

## Build

Describe what you need in your own words. The Agent does the technical work, then stays with the app after launch.

### The Agent

An AI agent that builds your app from a conversation, then keeps looking after it.

> Ask for it like this: “Build a holiday planner for the team, with approval from each person's manager.”

- Asks only the questions that matter, then builds, tests and releases the app.
- Starts from what you already have: attach spreadsheets, documents, presentations, PDFs or images.
- Stays with the app. Ask for changes in the same conversation weeks later, and it picks up where it left off.
- Runs on your organisation's own AI accounts: sign in with ChatGPT, or add an OpenAI or Anthropic API key.

### Your own coding agent

Prefer your own tools? Codex, Claude Code, ChatGPT and Claude can build on OpenCloud too.

- Connect once. You approve which app it can work on, and your password is never shared with it.
- It follows the same steps as the Agent: build in a private preview, test, then release.
- A command line tool offers the same steps for people who work in a terminal.

Docs: https://docs.opencloud.ai/getting-started/agent-integrations

### Build system

Turns your app's code into a finished release, the same way every time.

- Builds run in a locked-down space of their own, with no access to your passwords, keys or data.
- The only thing a build can reach is the public library of code packages.
- Builds that take too long or use too much are stopped, so one app can't slow down the others.
- The finished build is kept with the version that was tested, so what you approved is exactly what goes live.

Protects you from: A build step quietly reaching your passwords or data.

Docs: https://docs.opencloud.ai/guides/deployments

### One description per app

Each app has one short file that lists everything it uses.

- Its server code, background jobs, schedules, web addresses, alerts and the passwords it needs are all listed in one place.
- OpenCloud checks the file before anything goes live, and anyone technical can review it.
- It names the passwords and keys the app needs, but never contains them.

Docs: https://docs.opencloud.ai/reference/manifest

### Starters and your brand

New apps start from tested building blocks, styled to look like your company.

- Ready-made screens and components, with accessibility built in.
- Your colours and fonts come through a theme, without OpenCloud's own branding in your apps.
- Working examples to open and try, such as a client portal, a simple CRM and a project board.

## Building blocks

The parts every app can use. They're already set up, so the Agent spends its time on what your app should do.

### Data

#### Database

A real database for every app, with rules for who can see and change each record.

> Ask for it like this: “Keep track of our clients, their projects and every invoice.”

- Each app has its own separate space in the database. One app can't read another app's data.
- Rules for who can see each record are always on, for every table, and can't be switched off. Without a rule that allows it, nobody can see a record.
- Changes to how the data is organised are tried on a throwaway copy before every release.
- The app's pages never hold database passwords. Every request runs as the person who is signed in.

Protects you from: The most common leak in AI-built apps: a table left open to anyone on the internet.

Docs: https://docs.opencloud.ai/guides/database

#### Files

Upload documents, photos and other files without setting up anything extra.

- A file can be private to the person who uploaded it, or shared across the app.
- Each file is saved together with its record, so the app always knows who it belongs to.
- Files can be up to 100 MB each.

Docs: https://docs.opencloud.ai/guides/storage

#### Live updates

Changes appear on everyone's screen as they happen, without refreshing.

- Good for shared boards, request queues and dashboards.
- An update only tells a screen that something changed. The screen then loads it with the viewer's own permissions, so nobody sees more than they should.

Docs: https://docs.opencloud.ai/guides/realtime

### Background work

#### Server code

Code that runs on OpenCloud's servers, for work that shouldn't happen in the browser.

> Ask for it like this: “When an order form is submitted, check it and send it to our supplier.”

- Each piece can be for signed-in people, for anyone, or only for the app itself, such as a schedule.
- It can call other services on the internet, and it can have its own web address so other services can send it updates.
- The passwords and keys it needs are handed to it when it runs, and never reach the browser.

Docs: https://docs.opencloud.ai/guides/functions-cron

#### Background jobs

Work that runs after the click, and doesn't get lost.

> Ask for it like this: “When someone uploads an invoice, read it and email finance the totals.”

- Jobs are saved before they run, so a restart or a busy moment doesn't lose them.
- If a job fails, it tries again by itself, waiting a little longer each time.
- A job that keeps failing is set aside with its last error, so nothing disappears silently.
- Every job has its own key, so a job that runs twice can be recognised and its work done only once.
- Jobs can wait until later, up to a week, and you choose how many run at once.

Protects you from: A supplier's outage quietly dropping work.

Not yet: Running jobs in a strict order or by priority, and cancelling or re-running a failed job.

Docs: https://docs.opencloud.ai/guides/functions-cron

#### Schedules

Run work at set times, such as every Monday at 9.

> Ask for it like this: “Every Monday at 9, email each manager a summary of their team's open requests.”

- Schedules follow your time zone, including the change to and from summer time.
- If a run is missed, for example during maintenance, it catches up once rather than many times.
- Every run is recorded, so you can see what happened and when.
- Schedules don't run by themselves in previews, so testing never sends real reminders.

Docs: https://docs.opencloud.ai/guides/functions-cron

#### Agent tasks

Hand recurring work to the Agent itself, such as checking a set of websites every week.

- The app starts a task on a schedule or when something happens, and the Agent does the work in a session of its own.
- The Agent can use a web browser for the task, then hands the results back to the app.
- Tasks run only on the live app, with the owner's permission.
- They use your organisation's AI accounts and count towards its AI budget.

Docs: https://docs.opencloud.ai/guides/agent-tasks

### People and access

#### Sign-in

People sign in with an email link or a password. There's no separate account system to build.

- One account works across every app a person has been given.
- A sign-in link only works in the browser that asked for it, so forwarding the email doesn't let anyone else in.
- Each sign-in lasts at most 30 days. Signing out on one device leaves the others signed in.

Docs: https://docs.opencloud.ai/guides/auth

#### Sharing and permissions

Decide who can use each app, and who can change it.

- An app can be private, shared with named people, open to your whole organisation, or public.
- The right to change an app can go to named people or to the whole organisation.
- New apps stay private until someone shares them.
- For private apps, OpenCloud checks access before any of the app's code runs.
- Inside the app, its database rules decide what each person sees, such as only their own requests.

Docs: https://docs.opencloud.ai/guides/auth

#### Apps for your customers

Public apps, such as a customer portal, can have their own sign-up and sign-in.

- Your customers don't need a OpenCloud account.
- Their accounts are kept apart from your organisation's, so a customer can never act as one of your people.

Docs: https://docs.opencloud.ai/guides/auth#apps-that-manage-their-own-sign-in

#### Access for scripts

Let a script or another system use an app's data, with a token you can revoke.

- A token works for one app only.
- It can use the app's data and server code, but it can't change the app itself, its secrets or its backups.
- It's shown once, and can be revoked at any time.

Docs: https://docs.opencloud.ai/guides/auth#programmatic-private-app-access

### Connect

#### Email

Apps can send email, and receive it.

> Ask for it like this: “Send a confirmation when someone books a room, and turn replies into notes.”

- Each app has its own addresses, so replies come back to the right app.
- An incoming email can start server code, for example to log a support request.
- Sending pauses by itself if too many messages bounce or are reported as spam, which protects your reputation.
- Email sent from a preview is captured, never delivered.

Docs: https://docs.opencloud.ai/guides/email

#### Notifications

Send notifications to people's phones and computers, even when the app isn't open.

- People turn them on for each device themselves.
- Notifications sent from a preview are captured, not delivered.
- Every notification sent is kept in a history for 30 days.

Docs: https://docs.opencloud.ai/guides/notifications

#### Integrations

Connect apps to the tools your company already uses.

- Google Calendar, Drive, Sheets, Docs and Slides; reports from Google Analytics, Search Console and Google Ads; HubSpot; Asana; Slack; Telegram; bank account data through GoCardless; and payments received in Wise.
- You connect an account once. Apps use it without ever seeing its password or keys.
- Every call an app makes through a connection is recorded.
- Previews get realistic made-up data, unless someone switches one connection to live, and that switch is recorded.

Docs: https://docs.opencloud.ai/guides/integrations

#### Your own integrations

Connect any other system once, and let every app in your organisation use it.

- One app provides the connection, and your other apps use it like a built-in one.
- Passwords and sign-ins for that system are stored once, and only the app that provides the connection can use them.
- It can bring changes in from that system too, such as new orders or updated records.
- Connections stay inside your organisation.

Docs: https://docs.opencloud.ai/guides/custom-integrations

#### AI features

Add AI to an app: summaries, drafts, details pulled from documents, and images.

> Ask for it like this: “Read each uploaded receipt and fill in the expense form.”

- They run on your organisation's AI accounts, in the order your admins choose.
- The app's code never sees the passwords or keys for those accounts.
- A request can include files, such as photos or a PDF.

Docs: https://docs.opencloud.ai/guides/integrations#ai-connection-modes

## Tested before it's live

Every change takes shape in a private preview. Nothing reaches the people who depend on the app until it has been checked.

### Private previews

A private copy of the app, built fresh for each round of changes.

- It never contains live data or real passwords.
- Open it in your browser. It's clearly marked as not live, with desktop, tablet and mobile sizes.
- Only the exact version that passed its checks can be released.

Docs: https://docs.opencloud.ai/guides/development

### Made-up people and data

Tests use made-up data and three made-up people, never your real ones.

- An admin, a member and an outsider check that each person sees only what they should.
- Email and notifications are captured instead of sent.
- Integrations return realistic made-up data unless someone switches one to live, and that switch is recorded.

Docs: https://docs.opencloud.ai/reference/verification

### Automatic checks

Every new version is checked before anyone relies on it.

- The app's own tests walk through its important tasks, such as creating and approving a request.
- OpenCloud also looks for errors, broken links, pages that don't fit a phone screen, buttons without labels and tap targets that are too small.

Docs: https://docs.opencloud.ai/reference/verification

## Releases you can undo

Every release follows the same steps, and both the code and the data can be brought back.

1. Check the app and its description
2. Try database changes on a throwaway copy
3. Back up the database, if it's changing
4. Apply the changes
5. Switch everyone to the new version
6. Confirm the app is healthy

### Every release kept

Each release is fixed once it's made, and kept.

- The source code of any release can be downloaded at any time.
- If two people release at the same moment, the second is stopped instead of quietly replacing the first.
- Every release records who made it and when.

Docs: https://docs.opencloud.ai/guides/deployments

### Rollback

Go back to an earlier version of the app in one step.

- Rollback brings back the code and screens of the earlier version.
- It doesn't undo changes to the data. Restoring a backup does that.

Docs: https://docs.opencloud.ai/guides/deployments

### Backups

Bring an app's data back to an earlier point.

- The database is backed up by itself before every release that changes it.
- You can add daily or weekly backups on top.
- Backups are locked for 30 days, so nobody working on the app, including the Agent, can delete them early.
- Restoring a backup replaces the app's current data with the data in that backup.

Not yet: Uploaded files aren't included in backups yet.

Docs: https://docs.opencloud.ai/guides/deployments#recovery

## Looked after once it's live

The Agent that built the app keeps watch over it, and can fix what goes wrong.

### Logs, metrics and alerts

See what each app is doing, and hear about it when something's wrong.

- Logs, errors and request numbers for every app.
- Apps can track their own numbers, such as orders per hour.
- Alert rules ship with each release, so watching starts the moment it goes live.
- One summary shows failed jobs, missed schedules and rising errors.

Docs: https://docs.opencloud.ai/guides/telemetry

### Automatic repair

When an alert fires, the Agent that built the app can look into it and fix it.

- Someone who can change the app switches it on for that app.
- The Agent looks into the problem, tests a fix in a private preview, then releases it.
- The alert closes only after the fix is confirmed to work.
- If no AI account is available, the repair waits, and the conversation says so.

Docs: https://docs.opencloud.ai/guides/telemetry

### One history of changes

Changes made outside the Agent appear in its conversation.

- Releases and other changes made from the dashboard, a command line or another coding agent are recorded there, with who made them.
- So the Agent checks what changed before building on top of someone else's work.

### Visitor numbers

See how many people visit an app, where they come from, and what they use.

- Visits are counted by source, country, browser and operating system.
- IP addresses, full browser details and the pages people visit aren't stored.
- Previews and bots aren't counted.

## Security and control

OpenCloud enforces the important rules itself, whatever code an app contains.

### OpenCloud enforces

- Who can open a private app, checked before the app runs
- Each app's data kept apart from every other app's
- Record-level rules on every table, which can't be switched off
- No database or storage passwords in the app's pages
- Passwords and keys reach only the app's server code
- Sign-in, sessions and sign-in links
- Builds and Agent work in locked-down spaces
- A record of admin actions and integration calls

### Your app decides

- Which records each person can see, such as only their own requests
- What its server code does
- Who the app is shared with, set by the people who manage it

The Agent writes the app's rules, and the made-up test people check them before every release.

### What the Agent can do

For the app it's working on, the Agent has the same rights as the app's owner.

- It can release, roll back, restore a backup, change who has access, or delete the app, without asking again for each step.
- It can't reach other apps, your account, your organisation's settings, or OpenCloud itself.
- Its safety nets: every change is tested in a private preview first, the database is backed up before every release that changes it, backups are locked for 30 days, and any release can be rolled back.
- Everything it does is recorded in its conversation.

Docs: https://docs.opencloud.ai/getting-started/agents

### Apps belong to your organisation

Apps stay with your organisation when the people who built them move on.

- When someone leaves, their apps keep running, and your admins can still manage them.
- Organisation admins can manage every app.
- Connections an app relies on can be handed to the app, so they keep working after the person who set them up leaves.
- People with your company's email address can join by themselves, once you prove you own the domain.

### AI accounts and budgets

You choose which AI accounts pay for the work, and how much can be spent.

- Connect your organisation's accounts: sign in with ChatGPT, or add an OpenAI or Anthropic API key.
- Admins set a weekly budget for the organisation and a weekly limit for each person.
- Spending is counted as it happens, and work stops when a limit is reached.
- OpenCloud doesn't resell AI or add a markup.

### OpenCloud staff access

OpenCloud's platform administrators can open an app to check its safety or find the cause of a failure.

- They use their own name, never one of your people's accounts.
- They can't see secret values, and the app's own rules still apply to them.
- Reviewing an app doesn't give them a place in your organisation or control over the app.

Docs: https://docs.opencloud.ai/guides/auth

## Where it runs, and limits

The same product, three ways to run it. The full comparison is on the pricing page: https://design-opencloud-features-subpage-a450779.ocd.dev/pricing

| | Cloud | Dedicated | Private cloud |
| --- | --- | --- | --- |
| Runs on | OpenCloud's shared cloud | Your own server, hosted by us | Your cloud or data centre |
| Region | London, UK | Your choice | Anywhere you run it |
| Isolation | Per organisation | Own installation and database | Inside your network |
| Uptime commitment | No SLA | 99.9% SLA | Your infrastructure |
| Support | Email | Named contact | Priority |

### Limits

| What | Limit |
| --- | --- |
| File uploads | Up to 100 MB each |
| Background job tries | Up to 10 |
| Background job delay | Up to 7 days |
| Background jobs at once | Up to 20 per queue |
| Background job history | 14 days |
| App email | Up to 5,000 recipients an hour per app |
| Sign-in links | Work for 15 minutes |
| Sign-ins | Last up to 30 days |
| Previews | Last up to 24 hours |
| Backups locked | 30 days |
| Notification history | 30 days |
| App metrics history | 14 days |

### Not included yet

- Running background jobs in a strict order, or by priority
- Cancelling a background job, or re-running one that failed
- Restoring data to any chosen moment; restores go back to a backup
- Backups of uploaded files
- Built-in search across an app's records
- An uptime commitment on Cloud (Dedicated has one)
- Sending app email from your own domain on Cloud (Dedicated can)

## Questions

### Can the AI leak our data?

Each app's data is kept apart, and record-level rules are always on for every table, so a table can't be left open by mistake. The app's pages never hold database passwords. Before every release, made-up people check that each person sees only what they should.

### Can the Agent break the live app?

Changes are built and tested in a private preview first, and only the version that passed is released. The database is backed up before every release that changes it, and any release can be rolled back. If something goes wrong after launch, automatic repair can wake the Agent to fix it.

### Do tests touch real data or send real email?

No. Previews start empty and use made-up data. Email and notifications are captured, and integrations return made-up data unless someone switches one to live, which is recorded.

### What happens when the person who built an app leaves?

The app belongs to your organisation and keeps running. Admins can still manage it, and the Agent's conversation keeps the app's full history, so someone else can pick it up.

### Which AI providers see our data?

The provider behind the account doing the work, such as OpenAI or Anthropic. That's one of your organisation's connected accounts, or OpenCloud's own while your trial credit lasts.

### Where is our data stored?

On Cloud, in London, UK. Dedicated runs in the region you choose, and Private cloud runs wherever you run it.

### Can we take our app with us?

Yes. You can download the source code of every release, and read out the app's data and files with the command line tool. Private cloud runs the same software on your own infrastructure.

### Can OpenCloud staff see our apps?

Platform administrators can open an app to check its safety or find the cause of a failure. They use their own name, can't see secret values, and the app's own rules still apply to them.

Start a 14-day trial: https://agent.design-opencloud-features-subpage-a450779.ocd.dev

Docs: https://docs.opencloud.ai