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.
Copy this file into an empty directory, then set the values that match your environment.
services:securecontext:image: ghcr.io/secure-context/gateway:latestports:- "${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/0SC_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_healthyrestart: unless-stoppedpostgres:image: postgres:16-alpineenvironment:POSTGRES_USER: ${POSTGRES_USER:-securecontext}POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-securecontext}POSTGRES_DB: ${POSTGRES_DB:-securecontext}volumes:- postgres_data:/var/lib/postgresql/datahealthcheck:test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-securecontext} -d ${POSTGRES_DB:-securecontext}"]interval: 5stimeout: 5sretries: 5restart: unless-stoppedvolumes:postgres_data:
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.
mkdir -p securecontext-installcd 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/0docker compose up -ddocker compose psdocker compose logs securecontext --tail 100curl http://localhost:8080/healthz
After the gateway is running, use these URLs to open the admin UI and connect MCP clients.
Admin UIhttp://localhost:8080/admin/Health checkhttp://localhost:8080/healthzMCP metadatahttp://localhost:8080/.well-known/mcpMCP endpointhttp://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.
Deploy to Cloud Run with GitHub Actions, Workload Identity Federation, manual sandbox approval, and production-grade checks.
Open GCP deployment guideRun the same Docker Compose stack on EC2 and swap in RDS, ElastiCache, or other AWS-managed services when needed.
Open AWS deployment guideDeploy to Azure Container Apps with ACR and GitHub federated credentials.
Open Azure deployment guideBranding 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.
Local setup URLhttp://localhost:8080/admin/setupRemote setup URLhttps://<your-host>/admin/setup
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.
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.
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.
- Open
/admin/licensefrom the SecureContext admin UI. - Review the current plan, renewal state, expiry date, and capacity for users and MCP servers.
- Paste a signed license key into the Apply License form to activate or renew the gateway.
- Use Refresh to confirm the gateway is running with the expected license after the update.
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.
GET /admin/api/licensePOST /admin/api/licensePOST body{"key": "eyJhbGciOiJFZERTQSJ9..."}
License Status Response
{"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: bedrockname: "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-businessname: "Company Knowledge"config:application_id: "your-q-application-id"region: "us-east-1"# IAM role with Q Business permissionsassume_role_arn: "arn:aws:iam::123456789:role/SecureContextQ"
Slack
Configure OAuth token for Slack access.
connectors:- type: slackname: "Slack"config:# Bot OAuth token (xoxb-...)token: "${SLACK_BOT_TOKEN}"# Restrict to specific channels (optional)allowed_channels:- "engineering"- "incidents"- "product"# Enable search and postingcapabilities:- search- read_messages- post_messages # optional
Jira
Connect to Jira Cloud or Server.
connectors:- type: jiraname: "Jira"config:base_url: "https://acme.atlassian.net"# API token authenticationemail: "${JIRA_EMAIL}"api_token: "${JIRA_API_TOKEN}"# Restrict to specific projectsallowed_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
/healthzfor the liveness probe. - Check
/.well-known/mcpto confirm MCP discovery metadata is being served. - Connect one MCP client from the IDE setup section and confirm tool discovery succeeds.
- Open
/admin/overviewand 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/licenseto review plan, limits, expiry, and grace-period state. - Use
/admin/usageto review client and tool activity. - Use
/admin/auditfor operational audit history. - Use
/admin/approvalsand/admin/guardrailsto 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/licensebefore the grace period ends. - Confirm the active license in the admin UI after every renewal or key change.
# Example operations checklist1. Confirm /healthz and /.well-known/mcp both respond as expected2. Open /admin/overview and verify the gateway is healthy3. Review /admin/license for plan, limits, expiry, and grace-period state4. Check /admin/usage, /admin/audit, /admin/approvals, and /admin/guardrails5. 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
{"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.
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_PASSWORDbefore 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=disableSC_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 RedisSC_DATABASE_CACHE_BACKEND=redisSC_DATABASE_CACHE_REDIS_URL=redis://default:redis-password@<redis-host>:6379/0# Optional: remote admin and remote MCP authSC_OAUTH_ISSUER_URL=https://accounts.google.comSC_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_PASSWORDOptional 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_DSNto 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=rediswhen you need a shared hot cache.
Deploy
- Create or choose a PostgreSQL instance and decide whether Redis is needed.
- Deploy the Cloud Run service with the SecureContext image.
- Inject the required environment variables and secrets.
- Open
/admin/setupon 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-central1curl https://<gateway-url>/healthzcurl 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/setupand 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/setupfor branding and remote OAuth. - Review
/admin/license,/admin/usage, and/admin/guardrailsafter first boot. - Distribute the final
https://<gateway-url>/mcpendpoint 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.
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
.envfile, 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_PASSWORDbefore exposing the service on a network.
Required Values
Baseline values
SC_HTTP_PORT=8080POSTGRES_USER=securecontextPOSTGRES_DB=securecontextPOSTGRES_PASSWORD=change-meSC_SECRETS_KEY=<base64-encoded-32-byte-key>SC_SETUP_PASSWORD=change-me-before-remote-access
Managed-service overrides
# Replace the bundled Postgres service with RDSSC_DATABASE_DSN=postgres://db-user:db-password@your-rds-endpoint:5432/securecontext?sslmode=require# Optional: switch the hot cache to Redis or ElastiCacheSC_DATABASE_CACHE_BACKEND=redisSC_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 varSC_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_PASSWORDIf you use RDS, also set:- SC_DATABASE_DSNIf you use Redis, also set:- SC_DATABASE_CACHE_BACKEND=redis- SC_DATABASE_CACHE_REDIS_URL
3. Start the stack
docker compose up -ddocker compose psdocker 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 overrideUse AWS RDS:- set SC_DATABASE_DSN to your RDS PostgreSQL connection string- remove or ignore the postgres service from your deployment processUse Redis or ElastiCache:- set SC_DATABASE_CACHE_BACKEND=redis- set SC_DATABASE_CACHE_REDIS_URL to your Redis endpointUse 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/healthzcurl 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_DSNvalue, security group rules, and whether you still intend to use the bundled Postgres container. - Stored secrets are not encrypted: set
SC_SECRETS_KEYor mount a file and useSC_SECRETS_KEY_FILE. - High cache churn or multi-node inconsistency: move from the default
badgercache backend to Redis withSC_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.
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_PASSWORDbefore exposing the admin UI remotely.
Required Values
Baseline runtime values
SC_DATABASE_DSN=postgres://db-user:db-password@<azure-postgres-host>:5432/securecontext?sslmode=requireSC_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 RedisSC_DATABASE_CACHE_BACKEND=redisSC_DATABASE_CACHE_REDIS_URL=redis://default:redis-password@<redis-host>:6379/0# Optional: remote admin and remote MCP authSC_OAUTH_ISSUER_URL=https://login.microsoftonline.com/<tenant-id>/v2.0SC_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_PASSWORDOptional 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 andswitch to:- SC_DATABASE_CACHE_BACKEND=redis- SC_DATABASE_CACHE_REDIS_URL
Deploy
- Create or choose Azure Database for PostgreSQL and decide whether Redis is needed.
- Deploy the Container App with the SecureContext image.
- Inject the required environment variables and secrets.
- Open
/admin/setupon 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 tsvcurl https://<gateway-url>/healthzcurl 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/setupand 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
- Review our security documentation for best practices
- Revisit the cloud deployment guides for platform-specific rollout details
- for custom connector development
Search docs
Jump to any section in documentation.