Documentation

Get SecureContext running in your environment in under an hour.

Installation

SecureContext is typically installed with Docker Compose. Copy the file below as your starting point, then adjust it for your environment if you want managed Postgres or Redis.

docker-compose.yamlRecommended

Copy this file into an empty directory, then set the values that match your environment.

docker-compose.yaml
services:
securecontext:
image: ghcr.io/secure-context/gateway:latest
ports:
- "${SC_HTTP_PORT:-8080}:8080"
environment:
SC_DATABASE_DSN: postgres://${POSTGRES_USER:-securecontext}:${POSTGRES_PASSWORD:-securecontext}@postgres:5432/${POSTGRES_DB:-securecontext}?sslmode=disable
# Hot-cache backend: "badger" (default, in-memory only) or "redis".
# To use Redis instead, set SC_DATABASE_CACHE_BACKEND=redis and provide
# SC_DATABASE_CACHE_REDIS_URL, for example:
# redis://default:your-password@redis:6379/0
SC_DATABASE_CACHE_BACKEND: ${SC_DATABASE_CACHE_BACKEND:-badger}
SC_DATABASE_CACHE_REDIS_URL: ${SC_DATABASE_CACHE_REDIS_URL:-}
# AES-256 key for encrypting stored connection secrets at rest.
# Generate one with: openssl rand -base64 32
# If SC_SECRETS_KEY is not set, stored secrets are kept without encryption.
SC_SECRETS_KEY: ${SC_SECRETS_KEY}
# Setup password used only for non-localhost access before SSO is configured.
# Change this before exposing the service on a network.
SC_SETUP_PASSWORD: ${SC_SETUP_PASSWORD:-admin}
SC_LOG_LEVEL: ${SC_LOG_LEVEL:-info}
depends_on:
postgres:
condition: service_healthy
restart: unless-stopped
postgres:
image: postgres:16-alpine
environment:
POSTGRES_USER: ${POSTGRES_USER:-securecontext}
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-securecontext}
POSTGRES_DB: ${POSTGRES_DB:-securecontext}
volumes:
- postgres_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-securecontext} -d ${POSTGRES_DB:-securecontext}"]
interval: 5s
timeout: 5s
retries: 5
restart: unless-stopped
volumes:
postgres_data:
Install

Save the compose file, then start the stack. The environment exports below are optional overrides if you want to change the defaults or point SecureContext at managed services.

terminal
mkdir -p securecontext-install
cd securecontext-install
# save docker-compose.yaml here
# optional overrides
# export SC_SECRETS_KEY=<base64-encoded-32-byte-key>
# export SC_SETUP_PASSWORD=<change-me-before-remote-access>
# export POSTGRES_PASSWORD=<change-me>
# export SC_DATABASE_DSN=postgres://db-user:db-password@your-postgres-endpoint:5432/securecontext?sslmode=require
# export SC_DATABASE_CACHE_BACKEND=redis
# export SC_DATABASE_CACHE_REDIS_URL=redis://default:redis-password@your-redis-endpoint:6379/0
docker compose up -d
docker compose ps
docker compose logs securecontext --tail 100
curl http://localhost:8080/healthz
Access

After the gateway is running, use these URLs to open the admin UI and connect MCP clients.

endpoints
Admin UI
http://localhost:8080/admin/
Health check
http://localhost:8080/healthz
MCP metadata
http://localhost:8080/.well-known/mcp
MCP endpoint
http://localhost:8080/mcp

Cloud Deployment Guides

Start with Docker Compose for local or single-host installs. The guides below are follow-on patterns for teams that want to adapt SecureContext to specific cloud environments.

Google CloudAvailable

Deploy to Cloud Run with GitHub Actions, Workload Identity Federation, manual sandbox approval, and production-grade checks.

Open GCP deployment guide
AWSAvailable

Run the same Docker Compose stack on EC2 and swap in RDS, ElastiCache, or other AWS-managed services when needed.

Open AWS deployment guide
AzureAvailable

Deploy to Azure Container Apps with ACR and GitHub federated credentials.

Open Azure deployment guide

Branding and SSO

SecureContext setup for branding and OAuth SSO happens in /admin/setup. This is the required path for remote admin access and for remote authentication to the gateway MCP endpoint.

Setup URL
admin-setup
Local setup URL
http://localhost:8080/admin/setup
Remote setup URL
https://<your-host>/admin/setup
Localhost

When you access SecureContext on localhost, the admin UI skips setup mode so you can evaluate the product immediately. This is only for local access and is meant to help you get started quickly.

Remote Access

When you access SecureContext remotely through a host or domain, setup in /admin/setup is mandatory. That setup includes your branding and OAuth SSO configuration.

What OAuth Covers

OAuth SSO is used only for remote admin access and for remote authentication to the SecureContext gateway MCP server. Configure it from /admin/setup before you expose remote admin or remote MCP access.

Licensing

SecureContext license management lives in /admin/license. That page shows the active plan, status, expiry, usage against limits, and lets an operator paste a signed license key to activate or renew the gateway.

Admin PageProject-backed
  1. Open /admin/license from the SecureContext admin UI.
  2. Review the current plan, renewal state, expiry date, and capacity for users and MCP servers.
  3. Paste a signed license key into the Apply License form to activate or renew the gateway.
  4. Use Refresh to confirm the gateway is running with the expected license after the update.
What The Gateway Stores

The active license is applied to the gateway from the admin page itself. SecureContext persists the current license key and reports its effective status, limits, and usage through the admin API.

license-api
GET /admin/api/license
POST /admin/api/license
POST body
{
"key": "eyJhbGciOiJFZERTQSJ9..."
}

License Status Response

admin-license.json
{
"status": "active",
"limits": {
"users": 50,
"mcp_servers": 5
},
"usage": {
"users": 12,
"mcp_servers": 3
},
"plan": "team",
"license_id": "abc-123",
"expires_at": "2027-03-01T12:00:00Z"
}

SecureContext can also show a grace-period warning when a license has expired but the gateway is still inside its grace window. Operators should replace the key before that window ends.

Connectors

Add connectors to expose your company's knowledge systems.

AWS Bedrock

Use IAM role assumption for secure access.

connectors:
- type: bedrock
name: "AI Models"
config:
region: "us-east-1"
model_id: "anthropic.claude-v2"
# IAM role to assume (recommended)
assume_role_arn: "arn:aws:iam::123456789:role/SecureContextBedrock"
# Or use instance profile / environment credentials
# use_default_credentials: true

Amazon Q Business

Use Q as an aggregated knowledge connector.

connectors:
- type: amazon-q-business
name: "Company Knowledge"
config:
application_id: "your-q-application-id"
region: "us-east-1"
# IAM role with Q Business permissions
assume_role_arn: "arn:aws:iam::123456789:role/SecureContextQ"

Slack

Configure OAuth token for Slack access.

connectors:
- type: slack
name: "Slack"
config:
# Bot OAuth token (xoxb-...)
token: "${SLACK_BOT_TOKEN}"
# Restrict to specific channels (optional)
allowed_channels:
- "engineering"
- "incidents"
- "product"
# Enable search and posting
capabilities:
- search
- read_messages
- post_messages # optional

Jira

Connect to Jira Cloud or Server.

connectors:
- type: jira
name: "Jira"
config:
base_url: "https://acme.atlassian.net"
# API token authentication
email: "${JIRA_EMAIL}"
api_token: "${JIRA_API_TOKEN}"
# Restrict to specific projects
allowed_projects:
- "PAYMENTS"
- "PLATFORM"
- "INFRA"
capabilities:
- search
- read_issues
- create_issues
- update_issues

Operations

After deployment, operate SecureContext through its runtime probes and admin surfaces. The main checks are gateway health, MCP discovery, owner access, license status, and the admin pages for usage, audit, approvals, and guardrails.

Runtime checks

  • Check /healthz for the liveness probe.
  • Check /.well-known/mcp to confirm MCP discovery metadata is being served.
  • Connect one MCP client from the IDE setup section and confirm tool discovery succeeds.
  • Open /admin/overview and confirm the gateway reports the expected posture.

Access model

  • Direct localhost access bypasses authentication and is treated as an owner session for local evaluation.
  • Remote admin access requires OAuth and owner role membership.
  • Remote MCP access also uses OAuth rather than localhost bypass.
  • If a request arrives through a proxy, SecureContext treats it as remote access rather than localhost.

Admin surfaces

  • Use /admin/license to review plan, limits, expiry, and grace-period state.
  • Use /admin/usage to review client and tool activity.
  • Use /admin/audit for operational audit history.
  • Use /admin/approvals and /admin/guardrails to review enforcement and runtime controls.

License operations

  • Community mode is the default when no license is applied.
  • SecureContext keeps a 14-day grace period after license expiry before falling back to community defaults.
  • Apply replacement keys from /admin/license before the grace period ends.
  • Confirm the active license in the admin UI after every renewal or key change.
operations.txt
# Example operations checklist
1. Confirm /healthz and /.well-known/mcp both respond as expected
2. Open /admin/overview and verify the gateway is healthy
3. Review /admin/license for plan, limits, expiry, and grace-period state
4. Check /admin/usage, /admin/audit, /admin/approvals, and /admin/guardrails
5. Test one real remote OAuth login and one real MCP client connection before broad rollout

IDE Setup

Generate client-specific install actions for Cursor, GitHub Copilot, Claude Code, Codex, and other MCP-compatible tools.

Quick action

Cursor

Use Cursor's MCP deeplink or drop the same config into its local mcp.json.

Config location
~/.cursor/mcp.json or .cursor/mcp.json
Auth expectation
Remote SecureContext should expose OAuth metadata so the client can complete sign-in when first used.
Note
Cursor supports one-click OAuth install for remote HTTP MCP servers.

Manual config

.cursor/mcp.json

.cursor/mcp.json
{
"mcpServers": {
"securecontext": {
"url": "https://securecontext.example.com/mcp"
}
}
}

Recommended path: use OAuth for remote SecureContext installs. The install links and commands above assume the gateway publishes MCP and OAuth metadata on the same base URL.

If you haven't configured OAuth yet, start with Branding and SSO. After the server is connected, your client should auto-discover tools like Atlas.ask, Atlas.searchSlack, and Atlas.createJiraTicket.

GCP Deployment Guide

On GCP, SecureContext is best treated as a single HTTP service with managed PostgreSQL behind it. Cloud Run is a good fit when you want a managed runtime and do not need the localhost bypass path used for local evaluation.

TargetCloud Run

Use a SecureContext gateway image for your deployment, inject runtime values with Cloud Run environment variables and Secret Manager, and pair the service with Cloud SQL PostgreSQL. Add Redis only if you want a shared hot cache.

Prerequisites

  • GCP project with billing enabled.
  • Cloud Run region selected, for example us-central1.
  • A SecureContext gateway image for deployment.
  • A Cloud SQL PostgreSQL instance or another reachable PostgreSQL service.
  • Secret Manager entries for values like SC_DATABASE_DSN, SC_SECRETS_KEY, and OAuth client credentials if you enable remote SSO.
  • A non-default SC_SETUP_PASSWORD before exposing the admin UI remotely.

Required Values

Baseline runtime values

SC_DATABASE_DSN=postgres://db-user:db-password@<cloud-sql-or-postgres-host>:5432/securecontext?sslmode=disable
SC_SECRETS_KEY=<base64-encoded-32-byte-key>
SC_SETUP_PASSWORD=<change-me-before-remote-access>
SC_LOG_LEVEL=info

Optional managed-service values

# Optional: switch the hot cache to Redis
SC_DATABASE_CACHE_BACKEND=redis
SC_DATABASE_CACHE_REDIS_URL=redis://default:redis-password@<redis-host>:6379/0
# Optional: remote admin and remote MCP auth
SC_OAUTH_ISSUER_URL=https://accounts.google.com
SC_OAUTH_CLIENT_ID=<google-oauth-client-id>
SC_OAUTH_CLIENT_SECRET=<google-oauth-client-secret>
SC_OAUTH_SCOPES=openid profile email

GCP Setup

1. Enable required APIs

gcloud services enable \
iam.googleapis.com \
iamcredentials.googleapis.com \
run.googleapis.com \
artifactregistry.googleapis.com \
serviceusage.googleapis.com \
--project <PROJECT_ID>

2. Create the Cloud Run service

Start with your SecureContext gateway image and inject the required runtime values directly into Cloud Run.

gcloud run deploy securecontext-gateway \
--image <securecontext-gateway-image> \
--region us-central1 \
--port 8080 \
--allow-unauthenticated

3. Inject environment values and secrets

At minimum, your Cloud Run service should provide:
- SC_DATABASE_DSN
- SC_SECRETS_KEY
- SC_SETUP_PASSWORD
Optional values:
- SC_DATABASE_CACHE_BACKEND=redis
- SC_DATABASE_CACHE_REDIS_URL
- SC_OAUTH_ISSUER_URL
- SC_OAUTH_CLIENT_ID
- SC_OAUTH_CLIENT_SECRET
- SC_OAUTH_SCOPES

Cloud SQL and Redis

  • Use Cloud SQL PostgreSQL for the main datastore in production-style GCP deployments.
  • Set SC_DATABASE_DSN to the Cloud SQL connection string you want the gateway to use.
  • Leave Redis unset for a simpler deployment, or add Memorystore and switch to SC_DATABASE_CACHE_BACKEND=redis when you need a shared hot cache.

Deploy

  1. Create or choose a PostgreSQL instance and decide whether Redis is needed.
  2. Deploy the Cloud Run service with the SecureContext image.
  3. Inject the required environment variables and secrets.
  4. Open /admin/setup on the public host and complete branding and OAuth if the service will be accessed remotely.

Verify

gcloud run services describe securecontext-gateway \
--project <PROJECT_ID> \
--region us-central1
curl https://<gateway-url>/healthz
curl https://<gateway-url>/.well-known/mcp
# Then complete /admin/setup if this is a remote deployment and test
# one real remote admin login plus one real MCP client connection.

Troubleshooting

  • Container failed to start: check the Cloud Run revision logs and confirm SC_DATABASE_DSN, SC_SECRETS_KEY, and any OAuth values are present.
  • Remote admin cannot sign in: complete /admin/setup and verify the Google OAuth callback URLs match the deployed host.
  • MCP clients connect locally but not remotely: remember that localhost bypass does not apply on Cloud Run. Remote access requires OAuth.

What Next

  • Complete /admin/setup for branding and remote OAuth.
  • Review /admin/license, /admin/usage, and /admin/guardrails after first boot.
  • Distribute the final https://<gateway-url>/mcp endpoint to clients only after remote login and tool discovery are working.

AWS Deployment Guide

For AWS, run the published SecureContext docker-compose.yaml on EC2. Keep the bundled Postgres service for a simple install, or point the same stack at RDS and Redis when needed.

TargetEC2 + Docker Compose

Use the same compose file from the docs page or download link, then change only the DSN and cache values if you move to AWS-managed services.

Prerequisites

  • An EC2 instance or Linux VM with Docker Engine and the Docker Compose plugin installed.
  • Security group rules that allow inbound traffic only on the ports you intend to expose.
  • A safe way to provide environment values, such as an .env file, AWS Systems Manager, or AWS Secrets Manager.
  • A PostgreSQL DSN ready for either the bundled local Postgres service or your final RDS deployment.
  • A base64-encoded 32-byte secrets key if you want stored tokens and secrets encrypted at rest.
  • An updated SC_SETUP_PASSWORD before exposing the service on a network.

Required Values

Baseline values

SC_HTTP_PORT=8080
POSTGRES_USER=securecontext
POSTGRES_DB=securecontext
POSTGRES_PASSWORD=change-me
SC_SECRETS_KEY=<base64-encoded-32-byte-key>
SC_SETUP_PASSWORD=change-me-before-remote-access

Managed-service overrides

# Replace the bundled Postgres service with RDS
SC_DATABASE_DSN=postgres://db-user:db-password@your-rds-endpoint:5432/securecontext?sslmode=require
# Optional: switch the hot cache to Redis or ElastiCache
SC_DATABASE_CACHE_BACKEND=redis
SC_DATABASE_CACHE_REDIS_URL=redis://default:redis-password@your-elasticache-endpoint:6379/0
# Optional: load the encryption key from a mounted file instead of a plain env var
SC_SECRETS_KEY_FILE=/run/secrets/securecontext-secrets-key

AWS Setup

1. Copy the embedded compose file to EC2

# Copy the docker-compose.yaml from the docs page into a local file first,
# then upload it to your host.
scp docker-compose.yaml ec2-user@<ec2-host>:/opt/securecontext/

2. Provide runtime values

These values are enough for the bundled Compose stack. Swap the DSN and cache settings later if you move to RDS or ElastiCache.

Set these values before you start the stack:
- SC_SECRETS_KEY
- SC_SETUP_PASSWORD
- POSTGRES_PASSWORD
If you use RDS, also set:
- SC_DATABASE_DSN
If you use Redis, also set:
- SC_DATABASE_CACHE_BACKEND=redis
- SC_DATABASE_CACHE_REDIS_URL

3. Start the stack

docker compose up -d
docker compose ps
docker compose logs securecontext --tail 100

Customize For AWS Services

The same compose file can stay in place while you point specific dependencies at AWS-managed services:

Use the bundled postgres container:
- leave SC_DATABASE_DSN unset in your .env override
Use AWS RDS:
- set SC_DATABASE_DSN to your RDS PostgreSQL connection string
- remove or ignore the postgres service from your deployment process
Use Redis or ElastiCache:
- set SC_DATABASE_CACHE_BACKEND=redis
- set SC_DATABASE_CACHE_REDIS_URL to your Redis endpoint
Use remote admin and MCP auth:
- complete /admin/setup on your EC2 host/domain
- configure OAuth before sharing remote access

Verify

curl http://<ec2-host>:8080/healthz
curl http://<ec2-host>:8080/.well-known/mcp
# Then complete /admin/setup if this is a remote deployment, and test
# one real remote admin login plus one real MCP client connection.

Troubleshooting

  • Gateway cannot reach Postgres: check the SC_DATABASE_DSN value, security group rules, and whether you still intend to use the bundled Postgres container.
  • Stored secrets are not encrypted: set SC_SECRETS_KEY or mount a file and use SC_SECRETS_KEY_FILE.
  • High cache churn or multi-node inconsistency: move from the default badger cache backend to Redis with SC_DATABASE_CACHE_BACKEND=redis.
  • Remote admin access fails: localhost bypass only applies to direct local requests. Remote admin and remote MCP access require OAuth setup in /admin/setup.

Azure Deployment Guide

On Azure, run SecureContext as a single HTTP service in Container Apps with PostgreSQL behind it. Start with a SecureContext gateway image and inject runtime values through Container Apps secrets and environment variables.

TargetContainer Apps

Pair Container Apps with Azure Database for PostgreSQL. Add Redis only if you want a shared hot cache.

Prerequisites

  • Azure subscription with permissions for Container Apps and Azure Database for PostgreSQL.
  • Resource group and Container Apps environment created.
  • A SecureContext gateway image for deployment.
  • Secret storage for SC_DATABASE_DSN, SC_SECRETS_KEY, and OAuth values if you enable remote SSO.
  • A non-default SC_SETUP_PASSWORD before exposing the admin UI remotely.

Required Values

Baseline runtime values

SC_DATABASE_DSN=postgres://db-user:db-password@<azure-postgres-host>:5432/securecontext?sslmode=require
SC_SECRETS_KEY=<base64-encoded-32-byte-key>
SC_SETUP_PASSWORD=<change-me-before-remote-access>
SC_LOG_LEVEL=info

Optional managed-service values

# Optional: switch the hot cache to Redis
SC_DATABASE_CACHE_BACKEND=redis
SC_DATABASE_CACHE_REDIS_URL=redis://default:redis-password@<redis-host>:6379/0
# Optional: remote admin and remote MCP auth
SC_OAUTH_ISSUER_URL=https://login.microsoftonline.com/<tenant-id>/v2.0
SC_OAUTH_CLIENT_ID=<oauth-client-id>
SC_OAUTH_CLIENT_SECRET=<oauth-client-secret>
SC_OAUTH_SCOPES=openid profile email

Azure Setup

1. Create the Container App

az containerapp create \
--name securecontext-gateway \
--resource-group <RESOURCE_GROUP> \
--environment <ENV_NAME> \
--image <securecontext-gateway-image> \
--target-port 8080 \
--ingress external

2. Provide runtime values

Required values:
- SC_DATABASE_DSN
- SC_SECRETS_KEY
- SC_SETUP_PASSWORD
Optional values:
- SC_DATABASE_CACHE_BACKEND=redis
- SC_DATABASE_CACHE_REDIS_URL
- SC_OAUTH_ISSUER_URL
- SC_OAUTH_CLIENT_ID
- SC_OAUTH_CLIENT_SECRET
- SC_OAUTH_SCOPES

3. Add PostgreSQL and optional Redis

Use Azure Database for PostgreSQL for production-style deployments.
Leave Redis unset for a simpler deployment, or add Azure Cache for Redis and
switch to:
- SC_DATABASE_CACHE_BACKEND=redis
- SC_DATABASE_CACHE_REDIS_URL

Deploy

  1. Create or choose Azure Database for PostgreSQL and decide whether Redis is needed.
  2. Deploy the Container App with the SecureContext image.
  3. Inject the required environment variables and secrets.
  4. Open /admin/setup on the public host and complete branding and OAuth if the service will be accessed remotely.

Verify

az containerapp show \
--name <APP_NAME> \
--resource-group <RESOURCE_GROUP> \
--query properties.configuration.ingress.fqdn -o tsv
curl https://<gateway-url>/healthz
curl https://<gateway-url>/.well-known/mcp
# Then complete /admin/setup if this is a remote deployment and test
# one real remote admin login plus one real MCP client connection.

Troubleshooting

  • Container app is unhealthy: inspect revision logs and confirm SC_DATABASE_DSN, SC_SECRETS_KEY, and any OAuth values are present.
  • Remote admin cannot sign in: complete /admin/setup and verify the Entra callback URLs match the deployed host.
  • MCP clients connect locally but not remotely: remote access requires OAuth. The localhost bypass does not apply to Azure-hosted deployments.

Next Steps

Search docs

Jump to any section in documentation.