Deploy

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

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

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

bash

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

Configuration

Configuration is supplied through environment variables. At minimum, set the API keys the service will accept; leave authentication enabled in any shared environment.

LEXICOR_API_KEYS — comma-separated keys accepted in the X-API-Key header.
LEXICOR_AUTH_DISABLED — development only. When set, the API accepts unauthenticated requests. Never enable this in a shared or production environment.

Keep auth on

LEXICOR_AUTH_DISABLED exists for local iteration only. A deployment reachable by anyone else must require X-API-Key.

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 once the service is ready to serve traffic.

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.

Enabling the live Try-it console

The Try it console in the API reference ships in simulated mode: it returns the documented example response entirely in the browser and makes no network request. To point it at a real deployment, two changes are required in the docs site itself:

Set LIVE_MODE = true in components/docs/TryItConsole.tsx.
Add your API origin to the connect-src directive of the site’s Content Security Policy in firebase.json:

firebase.json — CSP connect-src

connect-src 'self' https://cloudflareinsights.com https://api.your-domain.example

Why it’s off by default

A static docs site with a strict CSP cannot reach an arbitrary API host, and simulated mode keeps the public site from pointing at any live endpoint. Turn it on only for an environment where a callable API and issued keys already exist.

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.