Install Deeplinq

Deeplinq ships as one Go server. PostgreSQL is its system of record and durable job queue; S3-compatible storage holds source files; Weaviate holds retrieval vectors. Optional sidecars add extraction, browser crawling, tabular analysis, semantic memory, and model services.

Choose a path

Local development

Prerequisites

• Docker with Docker Compose;
• Go 1.26 or newer;
• enough memory for the services you enable. Document extraction, browser crawling, and local models are the heaviest components.

One-command setup

Clone the repository and run the setup wizard:

git clone <your-git-remote> deeplinq-engine
cd deeplinq-engine
make setup

Press Enter to accept the recommended answers. The wizard:

• generates a local .env with unique encryption, audit, admin, database, and service credentials;
• preserves every existing value when it is run again;
• installs the repository hooks and reconciles the least-privileged PostgreSQL roles, even against an existing database volume;
• builds and starts PostgreSQL, Garage, Weaviate, Redis, Jaeger, Docling, the crawler, memory services, Deeplinq, and Open WebUI;
• creates and funds a starter organization and issues its API key;
• optionally registers and verifies a model connector, configures its pricing, and grants the model to the starter organization;
• waits for /readyz before reporting the local URLs and next action.

Provider API keys are entered with masked input and sent directly to Deeplinq. They are sealed in PostgreSQL and are never written to .env. Generated local credentials are stored in the ignored .env file with mode 0600.

make setup is idempotent: rerunning it repairs missing database roles and services without replacing credentials or deleting data.

For unattended environments, accept safe defaults without prompting:

make setup SETUP_FLAGS="--non-interactive"

Manual setup

The wizard is the recommended path. To run the underlying development stack manually, install the hooks and start Compose:

make hooks
make dev

The manual path uses development fallback credentials when .env has not been created. Do not reuse those fallbacks outside local development.

The wizard prints the generated admin login once and preserves it in .env. Without the wizard, the manual development fallback remains admin / deeplinq; it is not a production credential.

Verify the process and its dependencies:

curl -fsS http://localhost:8080/healthz
curl -fsS http://localhost:8080/readyz

/healthz proves the process is alive. /readyz reports functional dependency health. Fix a critical dependency before onboarding tenants.

Preserve or reset local data

make dev-down   # stop services and keep volumes
make dev-reset  # stop services and delete local data

Registered connectors, pricing, datasets, and uploads survive make dev-down. make dev-reset intentionally starts from an empty database and storage set.

Production topology

Build the root Dockerfile once and deploy the same image for API traffic, workers, scheduling, and the embedded console.

Provision these durable dependencies before starting the engine:

1. PostgreSQL with three distinct roles: schema owner, engine_app, and engine_system;
2. an S3-compatible bucket;
3. a Weaviate deployment;
4. Redis when the browser admin console must survive engine restarts;
5. any optional sidecars required by the product features you enable.

Create the runtime database roles once:

CREATE ROLE engine_app LOGIN PASSWORD '...';
CREATE ROLE engine_system LOGIN PASSWORD '...';

The migration credential must own the schema. At boot Deeplinq applies migrations with DATABASE_MIGRATION_URL, closes that privileged pool, verifies the runtime role posture, and then serves requests through the least-privileged app and system pools.

Generate the root secrets with a secret manager or a trusted workstation:

openssl rand -base64 32  # SECRETS_KEY: exactly 32 decoded bytes
openssl rand -base64 32  # AUDIT_ANCHOR_KEY
openssl rand -base64 32  # ADMIN_PASSWORD, or generate with your password manager

Set at least:

ENVIRONMENT=production
DATABASE_MIGRATION_URL=postgres://...
DATABASE_APP_URL=postgres://engine_app:...@.../deeplinq
DATABASE_SYSTEM_URL=postgres://engine_system:...@.../deeplinq
S3_URL=s3://ACCESS:SECRET@storage.example.com/deeplinq?region=us-east-1
VECTOR_URL=weaviates://:API_KEY@weaviate.example.com:443
SECRETS_KEY=...
AUDIT_ANCHOR_KEY=...
ADMIN_USERNAME=admin
ADMIN_PASSWORD=...
JWT_AUDIENCE=deeplinq
PUBLIC_URL=https://api.example.com

Do not put model-provider keys in environment variables. Register them as connectors after boot; Deeplinq seals them at rest.

Terminate TLS in front of the engine and proxy every path, including streaming responses, to its HTTP listener. Set HSTS at the TLS boundary only after the entire domain tree is HTTPS-ready.

Production readiness check

Before onboarding the first organization:

• both /healthz and /readyz return 200;
• the admin console is reachable only through HTTPS;
• the three PostgreSQL URLs use distinct roles;
• the S3 bucket, Weaviate data, PostgreSQL, and audit keys are backed up;
• provider egress is allowlisted;
• logs capture X-Request-ID;
• the platform has at least one verified connector and a price for every model you plan to grant.

Continue with platform setup.