Phigon
Star the Phigon observer on GitHub13 Book a demo

Docs Guides

Business deployment

Business runs in your own environment. Your control plane, PostgreSQL database, activity history, delivery queues, archives, and backups must all belong to you. A cloud database in your own cloud account is supported, as is a database on your network.

Phigon does not connect the shared hosted application directly to your private database. Do not expose a database port to the public internet to finish setup.

Connect your database

  1. Book a demo to arrange a Business deployment and obtain the workspace's tenant UUID.
  2. Provision a dedicated PostgreSQL database with a writable primary and a database owner role for Phigon's schema migrations. Other database engines are not supported. Never point Phigon at an unrelated application's database.
  3. Put POSTGRES_URL in the customer deployment's secret manager. For a cloud or network database, use sslmode=verify-full and the provider's CA certificate. Supply sslrootcert when required. Passwords with special characters must be URL-encoded. Plain HTTP/unencrypted PostgreSQL is not an alternative for a remote database.
  4. Configure your own NATS_URL, CLICKHOUSE_URL, REDIS_URL, MINIO_ENDPOINT, archive bucket and archive credentials/workload identity. PostgreSQL alone does not store all activity. Keep all these services and their backups inside your chosen data boundary.
  5. Set PHIGON_DEPLOYMENT_MODE=business, PHIGON_BUSINESS_TENANT_ID, and PHIGON_AUTH_MODE=access_key on the control plane. Retain TLS and the data encryption keys. There is no machine limit to configure.
  6. Run /phigon-api check-storage inside the configured control-plane image. This checks PostgreSQL connectivity, TLS and schema permissions without migrating or changing data. Starting the service then applies Phigon's migrations and provisions the configured tenant. It refuses a database containing other tenants.
  7. Set PHIGON_PUBLIC_CONTROL_PLANE_URL and PHIGON_PUBLIC_GRPC_URL on the control plane. These are the public endpoints your machines reach, not internal Kubernetes service addresses; the Phigon app copies them into the observer's pairing commands.
  8. Create the first administrator key with /phigon-api access-key create --name "Owner" inside the control-plane image. In the Phigon app, choose Using your own Phigon server?, enter your control plane's address, and paste the key. Open Settings → Storage → Check connection. All services must report connected before inviting machine owners to pair.

Keep credentials in server secrets, not browser storage, source control, copied setup commands, screenshots, or support messages. Database changes take effect when the deployment restarts; the status button checks the currently running configuration and never rewrites it.

Local and cloud connectivity

  • Same server: localhost means the process or container's own network namespace. A database on the Docker host is not available at the container's localhost address. Use the reachable private DNS name and TLS.
  • Private network: run the control plane within the network or use your managed private connection/VPN. Allow access only from your Phigon services.
  • Cloud: allowlist the deployment's outbound address, verify the database hostname certificate, and size the connection budget for all replicas. Keep archives, queues and backups in your own account too.
  • Observer: its API endpoint and gRPC endpoint are different services. Your ingress must support bidirectional HTTP/2 streaming. Copy setup commands from the Phigon app signed in to your deployment; pairing remembers both endpoints for later runs.

An unavailable customer database does not trigger fallback to Phigon-hosted storage. The observer retains its encrypted delivery queue within its configured limits. Collection applies backpressure when that queue fills; restore storage promptly and review any coverage gaps after recovery.

Moving an existing hosted workspace

Moving a workspace does not migrate or delete existing data on its own. Treat migration as a separate, scheduled operation:

  1. Confirm the tenant identity, approved collection scope, retention requirements, target storage and backup ownership.
  2. Stop new writes and drain acknowledged delivery queues before the final export. Keep the original deployment recoverable until restoration is verified.
  3. Export only that tenant's records across PostgreSQL, activity history and archives. Do not restore a backup of a shared hosted database into a customer deployment. An automated tenant-wide export/import tool is not yet available; the move requires an operator-reviewed migration.
  4. Preserve encryption keys needed by the exported records and backups, then verify record counts, conversations, permissions, deletion jobs and replay in the target.
  5. Connect machines to the customer endpoints. Keep old observer data directories until their queued activity is acknowledged; a separate data directory is required when pairing a different control plane. A new pairing cannot decrypt a spool belonging to another credential.
  6. After the owner accepts the verified migration, explicitly schedule deletion of hosted records and backup expiry. Changing DNS does not remove old copies.

Explicitly configured AI services may still receive the data needed for those features. For a private deployment, review those integrations and observability exporters as part of your data boundary; use private providers or disable the relevant features when required.

Recover from a failed check

For PostgreSQL, check DNS, the server's route/firewall, database name, password encoding, CA certificate and write permissions. For activity or archive failures, check the corresponding customer service's health and credentials. Restart after correcting configuration, then run Check connection again. Errors shown in the browser do not include database passwords or connection strings.

Book a demo about a Business deployment