Self-host & operate

Self-hosting the Lexicor API

The Lexicor API is a stateless HTTP service you can run in your own environment, behind your own network and access controls. This page covers a single-node deployment; contact us for multi-tenant and federated topologies.

Overview

The service exposes the REST API documented in the API reference on a single port. It is designed to run as a container image; horizontal scaling is a matter of running more replicas behind your load balancer, since request handling is stateless.

Run the API

Run the container and publish the HTTP port:

docker run --rm -p 8000:8000 \
  -e LEXICOR_DEMO_API_KEY="lx-your-key" \
  lexicor/api:latest

Confirm it is serving by hitting the unauthenticated health check on the published port:

curl http://localhost:8000/v1/health

Configuration

Configuration is supplied through environment variables. Leave authentication enabled in any shared environment.

• LEXICOR_DEMO_API_KEY — bootstraps a single admin tenant whose key is accepted in the X-API-Key header. Suitable for a single-node install; multi-tenant deployments manage keys in a Postgres-backed tenant store instead (set LEXICOR_AUDIT_DB and provision tenants through the platform API).
• LEXICOR_AUTH_DISABLED — development only. When set, the API accepts unauthenticated requests. Never enable this in a shared or production environment; with LEXICOR_PRODUCTION=1 the service refuses to start if it is set.
• LEXICOR_PRODUCTION — enables fail-closed production guards: the service requires a Postgres-backed governance store (LEXICOR_GOVERNANCE_DB) and a Redis rate limiter (LEXICOR_REDIS_URL) rather than in-process fallbacks. Recommended for any multi-replica deployment.

Health and readiness

Two unauthenticated probes support orchestration and load balancers:

• GET /v1/health — liveness. Returns 200 once the process is up.
• GET /v1/ready — readiness. Returns 200 with a per-subsystem checks map. When a dependency check fails, the response is still HTTP 200 with "status": "degraded" in the body — readiness probes that gate traffic should parse the JSON, not just the status code.

Wire /v1/health to your liveness probe and /v1/ready to your readiness probe so traffic is only routed to ready replicas.

TLS and reverse proxy

Terminate TLS at a reverse proxy or load balancer in front of the API and forward to the service port. Standard hardening applies: forward the original client IP, set sensible request-body and timeout limits, and restrict who can reach the port directly.

Enterprise deployments

Multi-tenant isolation, federated cross-organization retrieval, audit-ledger retention, and metering are available for production deployments. These involve additional services and configuration beyond a single node — get in touch to scope a deployment.