Doorman API Gateway

A lightweight API gateway built for AI, REST, SOAP, GraphQL, and gRPC APIs. No specialized low-level language expertise required. Just a simple, cost-effective API Gateway built in Python. This is your application’s gateway to the world. 🐍

Features

Doorman supports user management, authentication, authorizaiton, dynamic routing, roles, groups, rate limiting, throttling, logging, redis caching, mongodb, and endpoint request payload validation. It allows you to manage REST, AI, SOAP, GraphQL, and gRPC APIs.

Launch With Docker

Ensure an env file exists at the repo root: ./.env (use ./.env.example as a reference). Keep this file outside the image and pass it at runtime. Note - this is set for development, update variables and hosts to reflect a production environment.

Quickstart

Copy-paste the commands below as-is.

# 1) Build the image
docker build -t doorman:latest .

# 2) Run the container (publishes backend 3001 and web 3000)
docker run --rm \
  --name doorman \
  -p 3001:3001 -p 3000:3000 \
  --env-file "$(pwd)/.env" \
  doorman:latest

• Backend: http://localhost:3001
• Web client: http://localhost:3000 (set WEB_PORT to change)

Detach and follow logs:

docker run -d --name doorman -p 3001:3001 -p 3000:3000 --env-file "$(pwd)/.env" doorman:latest
docker logs -f doorman
docker stop doorman

Override only the web port (optional):

docker run --rm --name doorman -p 3001:3001 -p 3002:3002 \
  -e WEB_PORT=3002 \
  --env-file "$(pwd)/.env" \
  doorman:latest

Alternative: mount an /env folder

# Prepare your env folder (example: ./env/production.env)
docker build -t doorman:latest .
docker run --rm --name doorman -p 3001:3001 -p 3000:3000 -v "$(pwd)/env:/env:ro" doorman:latest

Notes

• The container loads env without overriding already-set variables. Platform/injected env and /env/*.env take precedence over repo files.
• Required secrets: DOORMAN_ADMIN_EMAIL, DOORMAN_ADMIN_PASSWORD, JWT_SECRET_KEY. For HA, set MEM_OR_EXTERNAL=REDIS and configure Redis.
• The web client now uses next.config.mjs, so TypeScript is not required at runtime inside the container.

Frontend build-time env via --build-arg

You can bake public frontend env into the Next.js bundle during docker build without committing any file:

# Pass values at build time (used only by the web client build)
docker build \
  --build-arg NEXT_PUBLIC_SERVER_URL=http://localhost:3001 \
  --build-arg NEXT_PUBLIC_API_URL=http://localhost:3001 \
  --build-arg NEXT_PUBLIC_APP_URL=http://localhost:3000 \
  -t doorman:latest .

# Then run (backend env comes from ./.env at runtime)
docker run --rm --name doorman \
  -p 3001:3001 -p 3000:3000 \
  --env-file "$(pwd)/.env" \
  doorman:latest

Details

• Only NEXT_PUBLIC_* variables are exposed to the browser. Do not pass secrets.
• Build-args affect the frontend build output. Changing them requires a rebuild.
• The backend still reads its env at runtime from --env-file (or /env/*.env).

License Information

The contents of this repository are property of Doorman Dev, LLC.

Review the Apache License 2.0 for valid authorization of use.

View License - Apache-2.0

Disclaimer

Use at your own risk. By using this software, you agree to the Apache 2.0 License and any annotations found in the source code.

We welcome contributors and testers!