Skip to main content

Documentation Index

Fetch the complete documentation index at: https://archie.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

App Services control authentication, permissions, file storage, and the custom API gateway across your backend. Open any project, switch to the Backend Console, and the App Services section is where every cross-cutting concern that sits in front of your Data Model lives.

​
What’s in App Services

Authentication Providers

Configure how users sign in. Built-in Archie Auth, third-party providers, or both running side by side.

Role-Based Access

Define roles and the read, write, update, and delete permissions they grant on every table — including row-level filters.

File Manager

Connect a storage backend (S3, GCS, Azure Blob, Filestack) and serve user uploads through the API.

Custom APIs

Register HTTP routes that reverse-proxy to internal services with CORS, rate limiting, and circuit breakers.

​
How App Services fit together

The four sub-areas form one coherent surface around your data:
  • Authentication Providers decide who can sign in.
  • Role-Based Access decides what an authenticated user (or an API key) is allowed to do.
  • File Manager holds files that records reference.
  • Custom APIs sit in front of internal services and bring them under the same auth and rate-limiting model.
A request flowing through Archie touches each of them in turn: the auth provider issues the token, RBAC checks the operation against the caller’s roles, the GraphQL and REST APIs serve the data, the File Manager backs any file fields, and a Custom API route can wrap any of that with extra policy.

​
Per-environment configuration

Every App Services configuration is per-environment. Each environment maintains its own:
  • Active authentication providers and their secrets
  • Roles and their permissions
  • File storage providers
  • Custom API routes
When you branch a new environment, gateway routes and file-storage configurations can optionally be copied. Authentication provider secrets and OAuth credentials are never copied — they have to be re-entered in each environment for security reasons.

​
Permissions are the API surface

Whatever you configure in Role-Based Access is what the auto-generated GraphQL and REST APIs enforce. There’s no separate “API permission” layer — the role grid is the contract. External clients calling the API use tokens generated under Backend → Settings → API Keys. Roles attach to those keys the same way they attach to authenticated users.

​
FAQ

Under Backend → Settings → API Keys — see API Keys. Roles defined in Role-Based Access attach to those keys to control what they can do.
File storage providers and Custom API routes can be copied when you branch a new environment. Roles live per-environment. Authentication provider secrets are deliberately not copied — re-enter them in each environment.
Yes. Multiple providers can be active simultaneously — for example, Archie Auth for end users and an API Token provider for service-to-service traffic. See Authentication Providers.
Under Backend → Settings → Network. The same allowed-origins list applies to GraphQL and REST. For per-route CORS on a Custom API, configure it on the route itself.
The auth provider verifies who you are and issues a token. RBAC takes that identity (or an API key) and decides what it’s allowed to do on each table. Auth is the doorman; RBAC is the access policy inside.