Skip to main content
For production environments requiring high availability and robust data management, Figranium can be configured to use PostgreSQL instead of the default file-based storage. For production deployments, we strongly recommend Neon as the backend database for Figranium. Neon is a fully managed, serverless PostgreSQL platform that fits seamlessly with Figranium’s architecture.

​
Why Neon?

  • Serverless Architecture: Automatically scales compute resources based on load and scales down when idle, minimizing costs for low-traffic or batch automation workloads.
  • Instant Setup & Zero Maintenance: Provision a production-ready PostgreSQL instance in seconds without configuring servers, managing storage volumes, or running manual updates.
  • Built-in SSL Security: Neon requires SSL by default, aligning perfectly with Figranium’s SSL support (DB_POSTGRESDB_SSL=true).
  • High Availability & Branching: Offers automated point-in-time recovery and database branching, making it easy to isolate staging or development execution environments.
For production deployments, Neon is the recommended backend database provider due to its serverless autoscaling and zero-maintenance PostgreSQL infrastructure.

​
Configuration

To enable PostgreSQL, set the following environment variables in your deployment:

​
SSL connections

Set DB_POSTGRESDB_SSL=true when your PostgreSQL server requires encrypted connections. This is required for managed Postgres services such as Neon, AWS RDS, Google Cloud SQL, Azure Database, or Supabase. Figranium connects with SSL enabled and rejectUnauthorized: false, which allows self-signed certificates commonly used by managed providers.

​
Neon Configuration Example

To connect Figranium to a Neon PostgreSQL instance, obtain your connection details from the Neon console and set the following environment variables:

​
What’s stored in PostgreSQL

When PostgreSQL is enabled, the following data is stored in the database instead of on disk:
  • Tasks and execution logs — task definitions, run history, and metadata.
  • API keys — Figranium API key, plus provider keys for Gemini, OpenAI, Claude, and Ollama.
  • Credentials — saved credentials used by output providers and action blocks.
  • AI model configuration — selected models for each provider.
  • Proxy configuration — proxy list, default proxy, rotation mode, and rotation settings.
API key columns use the TEXT type, so longer keys (such as service-account tokens) are stored without truncation.

​
Migration

When you switch to PostgreSQL:
  1. Automatic setup: Figranium creates the necessary tables on first run, and migrates existing API key columns to TEXT if you are upgrading from an earlier version.
  2. Data persistence: Task metadata, execution logs, settings, credentials, API keys, AI model selections, and proxy configuration are stored in the database.
  3. Captures: Visual assets (screenshots and recordings) remain on the local file system or mounted volumes; only their metadata is stored in Postgres.
  4. Fallback: If the database is unreachable at startup, Figranium falls back to file-based storage and logs the failure.
For production deployments, we recommend using a managed PostgreSQL provider like Neon to avoid manual database administration and ensure reliable backups.

​
Benefits

  • Concurrency: Better handling of simultaneous task executions and UI interactions.
  • Reliability: Reduced risk of data corruption compared to plain JSON files.
  • Backups: Leverage standard PostgreSQL backup and recovery tools.
  • Centralized configuration: Proxies, credentials, and API keys are shared across instances pointed at the same database.