PostgreSQL

Automata accepts a PostgreSQL connection string, proves it before saving, and exposes catalog, query, and optional write tools through a connector token.

Create a database role

The database role is the real security boundary. Start with only the schemas and tables the connector requires:

CREATE ROLE automata_reader LOGIN PASSWORD '<strong-password>';
GRANT CONNECT ON DATABASE app TO automata_reader;
GRANT USAGE ON SCHEMA public TO automata_reader;
GRANT SELECT ON public.customers, public.invoices TO automata_reader;

Add the connection

Create a PostgreSQL database connection and paste the DSN:

postgresql://automata_reader:<password>@db.example.com:5432/app?sslmode=require

Automata connects before saving. Rotating the connection string later does not invalidate connector tokens because tokens identify the connection, not the current credential.

Read and write access

New PostgreSQL tokens start with read tools enabled and run-statement disabled. For controlled writes, grant the exact INSERT, UPDATE, or DELETE privileges to the role, then explicitly add run-statement to the token.

Query safeguards

Every statement is restricted to one extended-protocol statement and checked with EXPLAIN (FORMAT JSON, VERBOSE) before execution.

• run-query accepts SELECT, WITH, VALUES, or TABLE in a read-only transaction.
• run-statement accepts only INSERT, UPDATE, DELETE, or MERGE.
• DDL, TRUNCATE, COPY, and CREATE TABLE AS are refused.
• Functions outside pg_catalog, SECURITY DEFINER functions, and dangerous built-ins are refused.
• Writes over maxRows roll back in full.
• UPDATE and DELETE without WHERE require allowWholeTable: true.

Private network targets

The outbound host guard rejects private and loopback destinations by default. Set NUXT_ALLOW_PRIVATE_TARGETS=true only for local or single-tenant self-hosting where private connectivity is intentional.

Automata always refuses targets that resolve to its own PocketBase, Evolution API, or Evolution database, regardless of that setting.