Deployment

The dedicated per-customer deployment model and what the customer prepares to connect securely.

3 min read

This page is for the people who manage infrastructure and databases on the customer side. It describes how Admin as a Service is deployed and what the customer needs to prepare. The customer does not install or operate the platform.

Dedicated deployment model

Each customer gets a separate, isolated deployment with:

Dedicated data: accounts, projects, actions, views and the audit log are not stored together with other customers’ data.
Dedicated encryption keys: connection details and secrets are encrypted with keys used only by that customer’s deployment.
A dedicated domain for the interface.
A dedicated, fixed egress IP: every connection from the platform to the customer’s databases or APIs leaves from one static IP address that stays the same for as long as the service is in use. The firewall only needs to allow that address.

The first Owner account is created during onboarding. The owner then creates accounts for colleagues and creates projects. See Organization and users.

Customer-side preparation

Open a network path to the database or API. Allow the deployment’s egress IP (which we provide) into the database or API to connect, for example in a security group or firewall. Do not open access to a wider range than needed.
Create a least-privilege database account. Do not use a superuser or the application’s own account. Create a dedicated account for Admin as a Service with only the rights the planned actions need.
Prepare TLS. For cloud databases or an internal CA, have the CA file in PEM format ready (for example the provider’s bundle) to use On, verify the certificate. If the database requires client certificates, also prepare the certificate and a private key without a passphrase.
For HTTP APIs, prepare the list of hosts to call and the tokens to set as headers (do not put a username/password in the URL). HTTP data sources currently only store configuration and support connection tests; actions that call an HTTP API are not available yet.
Prepare user IPs (optional). To allow actions to run only from the office network or VPN, prepare the list of IPs/CIDRs for each environment’s IP allowlist. See Environments.

Database account recommendations

Separate read and write accounts:

A read-only account for read actions. If a read replica is available, point this account at it so queries do not affect the primary database.
A separate write account, with write rights only on the exact tables and columns that need changing.
Sensitive columns: do not grant access to the base table; grant a view that masks the data (for example showing only the first digits of a phone number).

Example for PostgreSQL:

-- Read-only account
CREATE ROLE tool_ro LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE appdb TO tool_ro;
GRANT USAGE ON SCHEMA public TO tool_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO tool_ro;

-- Write account: may only change the status and updated_at columns of orders
CREATE ROLE tool_rw LOGIN PASSWORD '...';
GRANT SELECT, UPDATE (status, updated_at) ON orders TO tool_rw;

In Admin as a Service, declare these two accounts as two data sources (for example orders_ro and orders_rw). Put the actions that use orders_rw in restricted permission mode and grant them only to the people who need them. See Data sources and Access control.

Coming soon

The following are not in the current release:

Bridge: a connector gateway that the customer runs inside its private network (VPC). The platform can then reach databases in private subnets without exposing them, and database credentials do not need to be stored on the platform.
SSO/SAML: sign-in through the company’s identity provider.
Execution review: approval of individual runs with specific parameters before they execute.
Audit streaming: delivery of the audit log to the customer’s own storage or monitoring systems.

Currently, databases must be reachable from the deployment’s egress IP, and users sign in with email and password.