powered by

How a project fits together

A project is a Postgres database, an instant REST API, background workers, file storage and search, all run for you. See how the parts connect.

Last updated

Anythink is a managed backend. Each project gets its own database, a REST API in front of it, background workers, file storage and a search index, and Anythink runs all of it. There's nothing to deploy, patch or scale. This page shows how the parts connect and what each project keeps to itself, so you can judge whether it fits what you're building.

It stays at the level a customer needs. It doesn't cover Anythink's internal services or hosting setup.

The shape of a project

text
  Your app, the Anythink dashboard, the CLI, an AI assistant over MCP
                               |
                               |  HTTPS, REST + JSON
                               v
                 +-----------------------------+
                 |  REST API for your project  |
                 |  sign-in, permissions,      |
                 |  rate limits, validation    |
                 +--------+----------+---------+
                          |          |
              read/write  |          |  publish a message
                          v          v
              +-----------------+  +---------------+
              |  Postgres       |  | Message queue |
              |  your records,  |  +-------+-------+
              |  users, roles   |          |
              +-----------------+          v
                                   +---------------+      +----------------------+
         +---------------+         | Workers       | ---> | Email and push       |
         | File storage  | <------ | workflows,    |      | delivery             |
         | (S3-compatible| ------> | search index, |      +----------------------+
         |  + CDN for    |         | imports, file |
         |  public files)|         | processing    | ---> Search index
         +---------------+         +---------------+
                                           |
                                           '--> calls back into the REST API

  AnythinkPay (Stripe and Apple) sits alongside, reporting into the same API

Everything in your app goes through the REST API. The dashboard, the CLI and an assistant over MCP all call it too, so none of them has a back door that skips your permissions. See Core concepts.

The REST API and your data

The API is the front door to your project's Postgres database. When you save an entity, its endpoints exist straight away: Anythink creates the table and routes for you, with no deployment step. Every request is checked before it reaches your data:

  • Who you are. A signed-in user or an API key. See API keys.
  • What you can do. Your role's permissions on that entity, then row-level security if you've turned it on for the entity. See Control access and Groups and row-level security.
  • Whether the request is allowed through. Each project and client address has a per-minute request cap. See Limits and quotas.

Records live in Postgres, so the types, relationships, filters and ordering you set up are real database behaviour, not an emulation. See Call the instant REST API.

The API is REST over HTTP and JSON. There's no GraphQL endpoint and no realtime subscription: clients fetch data over REST. There are no serverless functions either. To run logic in your backend, use workflows.

Background work: the queue and the workers

Anything slow or unreliable runs away from the request. The API puts a message on a queue and returns, and workers pick the message up. That keeps a request quick when you save a record, and lets slow work retry or queue up without blocking anyone.

Work What happens
Search indexing A create, update or delete queues an index change, and a worker applies it. A change is searchable a moment after you save it. See Search.
Workflows A trigger (a record change, a schedule or an API call) queues a job. A worker runs the steps in order. See How workflows work.
Email A workflow step or a system email queues a message, and a worker renders and sends it. See Email templates.
Push notifications A workflow step queues the send, and a worker delivers it to your users' devices. See Push notifications.
Imports and file processing A CSV import runs in batches on a worker. A worker reads the details of an uploaded file (such as an audio or video duration) after the upload finishes.

Workers don't read your database directly. They call back into your project's REST API, so a workflow step goes through the same permission and validation checks as any other request.

Because the work is asynchronous, a few things are worth knowing. A workflow API trigger returns 204 No Content before the job finishes, so check the job's status in the history. A failed step stays failed: there's no automatic retry for workflow steps. And a record you've just saved can take a moment to appear in search.

Files

Uploaded files go to S3-compatible object storage, not the database. The API streams the upload straight through to storage, so a large file doesn't sit in memory. Records keep a reference to the file.

  • Private files are served through a short-lived signed link, issued only to a caller who has permission to read files.
  • Public files are served from a CDN, which keeps downloads fast and takes the load off the API.

Each file is stored under your project's own path in the bucket. See Upload and manage files for how files, public access and limits work.

Search uses a dedicated search index, powered by Meilisearch, kept in step with your records by the workers above. Each entity in a project has its own index. You choose which fields are searchable. Signed-in search respects your permissions, and public search returns only the fields you've marked as publicly searchable.

Email and push delivery

Your project sends email and push notifications through delivery services that Anythink runs and connects for you. Email counts towards your plan's daily allowance. Push goes to your users' devices through Firebase Cloud Messaging and the browser push services. You configure what to send and when in a workflow, and you don't need your own mail server or push gateway.

Payments

AnythinkPay takes payments and runs subscriptions through Stripe (using your own connected Stripe account) and Apple in-app purchases. Both providers report into the same plan, subscription and entitlement records in your project, so your app checks access one way. Anythink can also notify your project of payment events by webhook, and retries a failed delivery. See How payments and subscriptions work.

Hosting and regions

Anythink hosts and operates every project, and there's no self-hosted edition. Projects run in London (lon1), which is the only region the portal and the CLI offer today. Other regions are available on request for customers on higher plans. See Account, billing and projects.

What each project keeps to itself

Projects are isolated from each other. You can run development, staging and production as separate projects and know one can't read another's data.

Per project How it's kept apart
Records Each project's data sits in its own database schema, and every query is scoped to that project.
Search Each entity in a project has its own search index.
Files Files are stored under the project's own path in object storage.
Users, roles and API keys Created per project. A sign-in or key from one project doesn't work in another.
Secrets and connections Stored per project, and secret values are encrypted at rest. See Store API keys and tokens as secrets.
Plan, quotas and billing Chosen and counted per project.

The services themselves, the API, the queue and the workers, are shared by many projects. What's separate is the data and the access to it. See Environments and migrating data for setting up separate projects.

What this page commits to

This page makes three commitments: the API is served over HTTPS, secret values are encrypted at rest, and each project's data is kept apart from every other project's. It doesn't promise more than that. What your users can reach inside a project depends on the roles, permissions and row-level security you set up, so configure those as part of building your app.

Next steps