Bifrost 1.6.6

Option A: AWS Marketplace console

• Open the SecureAnyCloud Hardened Ollama, LiteLLM & Self Hosted LLM Server AMIs listing on AWS Marketplace. Choose View purchase options, then Subscribe. One subscription covers every version in the listing.
• Once the subscription is active, choose Launch your software.
• Choose One-click launch from AWS Marketplace, or Launch from EC2 Console for the full launch wizard. In Version, choose Bifrost 1.6.6 on Ubuntu 24.04, then choose your Region.
• Pick an instance type and your key pair. m5.large is recommended, and the software charge is $0.04 per vCPU per hour.
• Set the security group. The listing's default group opens SSH (22), HTTP (80) and HTTPS (443). Restrict SSH to your own IP address, and restrict 80 and 443 to the networks your applications and administrators use. This gateway spends your provider credit.
• Choose your VPC and subnet and leave the metadata defaults, because the image already requires IMDSv2. Then choose Launch.

Option B: AWS CLI

Run this on your own workstation. It creates a security group that allows SSH from your management address and HTTPS from your application network, then launches the instance.

Replace the AMI ID with the one shown for your Region on the Marketplace launch page. Replace the VPC, subnet, key pair and CIDR ranges with your own:

SG=$(aws ec2 create-security-group --group-name bifrost-gateway \
  --description "Bifrost gateway" --vpc-id vpc-0123456789abcdef0 \
  --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 22 --cidr <your-mgmt-cidr>
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 443 --cidr 10.0.0.0/16
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 80 --cidr 10.0.0.0/16
aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids "$SG" \
  --subnet-id subnet-0123456789abcdef0 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=bifrost-gateway}]'

You do not need --metadata-options: the AMI already makes IMDSv2 required.

Connect as ubuntu with the key pair you chose:

ssh -i ~/.ssh/my-key-pair.pem ubuntu@<public-ip>

First boot finishes within a minute of launch. It sets the hostname Bifrost is served as (the instance's public DNS name when it has one) and creates the TLS certificate for it. It generates the dashboard password, the virtual key and the gate token, and proves that the gate refuses anonymous and wrong credentials. It then starts Bifrost and nginx and writes /root/bifrost-credentials.txt (mode 0600, root).

These commands list the entries in that file without showing the secret values:

sudo grep -E '^BIFROST_(URL|USERNAME)=' /root/bifrost-credentials.txt
sudo grep -oE '^[A-Z_]+=' /root/bifrost-credentials.txt
sudo stat -c '%a %U:%G' /root/bifrost-credentials.txt

BIFROST_URL=https://ec2-44-211-166-21.compute-1.amazonaws.com/ BIFROST_USERNAME=bifrost BIFROST_URL= BIFROST_USERNAME= BIFROST_PASSWORD= <set-at-first-boot>= 600 root:root

The file holds these values:

• BIFROST_URL: the dashboard and API address of this instance
• BIFROST_USERNAME: the dashboard username (always bifrost)
• BIFROST_PASSWORD: the dashboard password, generated on this instance
• BIFROST_VIRTUAL_KEY: the sk-bf-... virtual key your applications authenticate with

To read the password and key, run sudo cat /root/bifrost-credentials.txt in your own session. Store them in your secrets manager.

Check that the first-boot unit, Bifrost and nginx are active, and that only sshd and nginx listen beyond loopback. Bifrost itself is on 127.0.0.1:8080, so the nginx gate is the only way in.

systemctl is-active bifrost-firstboot.service bifrost.service nginx.service
sudo ss -Htlnp | awk '{print $4, $6}' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g' | sort -u curl -sk https://127.0.0.1/nginx-health

active active active 0.0.0.0:22 users:(("sshd"),("systemd")) 0.0.0.0:443 users:(("nginx"),("nginx"),("nginx")) 0.0.0.0:80 users:(("nginx"),("nginx"),("nginx")) 127.0.0.1:8080 users:(("bifrost-http")) 127.0.0.53%lo:53 users:(("systemd-resolve")) 127.0.0.54:53 users:(("systemd-resolve")) [::]:22 users:(("sshd"),("systemd")) [::]:443 users:(("nginx"),("nginx"),("nginx")) [::]:80 users:(("nginx"),("nginx"),("nginx")) OK

nginx answers /nginx-health itself and reveals nothing about your configuration, so it is safe to use as a load balancer health check.

Anonymous requests to the inference endpoints, the metrics and the admin API are all refused. So is a virtual key that is wrong by one character. This instance's own key is accepted:

for R in /v1/models /metrics /api/config /api/governance/virtual-keys /api/providers; do printf '%s -> %s\n' "$R" "$(curl -sk -o /dev/null -w '%{http_code}' https://127.0.0.1$R)" done curl -sk -o /dev/null -w 'anonymous POST /v1/chat/completions -> %{http_code}\n' \
  -X POST -H 'Content-Type: application/json' -d '{}' https://127.0.0.1/v1/chat/completions
K=$(sudo grep '^BIFROST_VIRTUAL_KEY=' /root/bifrost-credentials.txt | cut -d= -f2-)
curl -sk -o /dev/null -w 'wrong key -> %{http_code}\n' -K <(printf 'header = "Authorization: Bearer %sX"\n' "$K") https://127.0.0.1/v1/models
curl -sk -o /dev/null -w 'this instance key -> %{http_code}\n' -K <(printf 'header = "Authorization: Bearer %s"\n' "$K") https://127.0.0.1/v1/models

/v1/models -> 401 /metrics -> 401 /api/config -> 401 /api/governance/virtual-keys -> 401 /api/providers -> 401 anonymous POST /v1/chat/completions -> 401 wrong key -> 401 this instance key -> 200

The gate accepts six equivalent proofs. Each is compared exactly, and each is unique to this instance:

• HTTP Basic with BIFROST_USERNAME / BIFROST_PASSWORD, used by your browser and by curl -u
• A gate cookie issued after the browser signs in (Secure, HttpOnly, SameSite=Lax), used by your browser on every dashboard API call
• Authorization: Bearer <virtual key>, used by the OpenAI SDK, LiteLLM and LangChain
• x-api-key: <virtual key>, used by the Anthropic SDK
• x-goog-api-key: <virtual key>, used by the Google GenAI SDK
• x-bf-vk: <virtual key>, Bifrost's native header

The last four are the header idioms Bifrost itself uses for virtual keys. Your application sends one credential that satisfies both the gate and Bifrost's own governance check.

Browse to BIFROST_URL (https://<public-dns-name>/). The certificate is self-signed, so your browser warns once. Accept it for this host, or install your own certificate (see Step 8).

The browser then asks for a username and password. Enter BIFROST_USERNAME and BIFROST_PASSWORD.

The dashboard is the full Bifrost control plane: observability, model providers, governance, guardrails, the MCP gateway, routing rules and the prompt repository. On a new instance, Models > Model Providers is empty.

The image ships with no provider configured, so no two customers ever share a key. Confirm it from the shell:

U=$(sudo grep '^BIFROST_USERNAME=' /root/bifrost-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^BIFROST_PASSWORD=' /root/bifrost-credentials.txt | cut -d= -f2-)
curl -sk -K <(printf 'user = "%s:%s"\n' "$U" "$P") https://127.0.0.1/api/providers; echo

{"providers":[],"total":0}

In the dashboard, go to Models > Model Providers > Add provider, choose your provider and paste your own API key. Changes take effect immediately. Provider keys are stored in the SQLite configuration store under /var/lib/bifrost/data, which only the bifrost user can read.

Add a self-hosted model server in your VPC, for example an Ollama instance from the same listing, the same way with its base URL. Bifrost refuses link-local and private-range base URLs by default. If you route to a private address, check the provider's network settings in the Bifrost documentation.

Set your SDK's base URL to https://<BIFROST_HOST>/v1 and its API key to BIFROST_VIRTUAL_KEY. That single value authenticates through the gate and identifies the virtual key inside Bifrost.

Copy the instance's certificate (/etc/ssl/bifrost/bifrost.crt) to your client and trust it. Alternatively, put a certificate your clients already trust in front (Step 8).

With the OpenAI Python SDK, the only change to existing code is base_url and api_key:

from openai import OpenAI client = OpenAI( base_url="https://<BIFROST_HOST>/v1", api_key="<virtual key>", ) response = client.chat.completions.create( model="openai/gpt-4o-mini", messages=[{"role": "user", "content": "Hello!"}], ) print(response.choices[0].message.content)

Once you have added a provider, send a chat completion through the gateway:

curl --cacert bifrost.crt -X POST https://<BIFROST_HOST>/v1/chat/completions \
  -H "Authorization: Bearer <virtual key>" -H "Content-Type: application/json" \
  -d '{"model":"openai/gpt-4o-mini","messages":[{"role":"user","content":"Hello!"}]}'

The model field takes the form provider/model, so the same endpoint reaches every provider you configure.

Governance: budgets, rate limits and more keys

First boot created one virtual key, the SecureAnyCloud appliance key, and turned on authentication for inference. Exactly one key exists on a new instance:

U=$(sudo grep '^BIFROST_USERNAME=' /root/bifrost-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^BIFROST_PASSWORD=' /root/bifrost-credentials.txt | cut -d= -f2-)
curl -sk -K <(printf 'user = "%s:%s"\n' "$U" "$P") https://127.0.0.1/api/governance/virtual-keys | jq -r '.virtual_keys[] | [.name, .is_active] | @tsv'
curl -sk -K <(printf 'user = "%s:%s"\n' "$U" "$P") https://127.0.0.1/api/config | jq '.client_config.enforce_auth_on_inference'

sac appliance key true true

In Governance > Virtual Keys, you can issue a key per team, application or customer. Each key can have a budget, a rate limit, an expiry and a restriction to specific providers or models. A new key starts with no provider allowed, so add the providers it may use.

Bifrost enforces the keys you issue in the dashboard. The nginx gate in front recognises only the appliance key and the dashboard credential, so a request that carries only a new key is refused at the gate with 401. To give each application its own key from outside the instance, put your own identity-aware proxy or API gateway in front of this instance and have it forward the appliance key.

Port 80 redirects to HTTPS on the configured hostname. The certificate covers that name, the instance's public and private addresses, localhost and 127.0.0.1:

H=$(sudo grep '^BIFROST_URL=' /root/bifrost-credentials.txt | cut -d= -f2- | sed -E 's#https://([^/]+)/#\1#')
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' "http://$H/v1/models" openssl x509 -in /etc/ssl/bifrost/bifrost.crt -noout -subject -enddate -ext subjectAltName

301 https://ec2-44-211-166-21.compute-1.amazonaws.com/v1/models subject=CN = ec2-44-211-166-21.compute-1.amazonaws.com, O = sac notAfter=Jan 21 19:07:58 2029 GMT X509v3 Subject Alternative Name: DNS:ec2-44-211-166-21.compute-1.amazonaws.com, IP Address:44.211.166.21, IP Address:172.31.90.0, IP Address:127.0.0.1, DNS:localhost

To use your own name, point a DNS record at the instance. An Elastic IP keeps the address stable across stops. Then run the helper. It records the name in /etc/sac/bifrost-hostname, issues a new self-signed certificate for it, updates the allowed origins and the credentials file, and reloads nginx:

sudo bifrost-set-hostname <your-dns-name>

For a publicly trusted certificate, put the instance behind an Application Load Balancer with an AWS Certificate Manager certificate. Alternatively, replace /etc/ssl/bifrost/bifrost.crt and bifrost.key with your own and run sudo systemctl reload nginx.

Bifrost's service carries the metadata block. nginx refuses cross-origin writes and requests for any hostname it was not configured with. Bifrost itself refuses a provider pointed at the metadata address:

systemctl show -p IPAddressDeny bifrost.service
H=$(sudo grep '^BIFROST_URL=' /root/bifrost-credentials.txt | cut -d= -f2- | sed -E 's#https://([^/]+)/#\1#')
U=$(sudo grep '^BIFROST_USERNAME=' /root/bifrost-credentials.txt | cut -d= -f2-)
P=$(sudo grep '^BIFROST_PASSWORD=' /root/bifrost-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -w 'cross-origin POST: %{http_code}\n' --cacert /etc/ssl/bifrost/bifrost.crt -K <(printf 'user = "%s:%s"\n' "$U" "$P") \
  -X POST -H 'Origin: https://evil.example' -H 'Content-Type: application/json' -d '{}' "https://$H/api/governance/virtual-keys" code=$(curl -s -o /dev/null -w '%{http_code}' -H 'Host: evil.example' http://127.0.0.1/ || true); echo "unknown Host: ${code} (connection closed by nginx)"
curl -s --cacert /etc/ssl/bifrost/bifrost.crt -K <(printf 'user = "%s:%s"\n' "$U" "$P") -H "Origin: https://$H" -H 'Content-Type: application/json' \
  -X POST -d '{"provider":"openai","network_config":{"base_url":"http://169.254.169.254/latest/meta-data"}}' "https://$H/api/providers"; echo

IPAddressDeny=168.63.129.16/32 fd00:ec2::254/128 169.254.169.254/32 cross-origin POST: 403 unknown Host: 000 (connection closed by nginx) {"is_bifrost_error":false,"status_code":400,"error":{"message":"Invalid base URL: link-local IP addresses are not allowed"},"extra_fields":{"routing_info":{}}}

The SecureAnyCloud build also proves, before the image is captured, that Bifrost refuses a provider whose hostname is later re-pointed at 169.254.169.254 (DNS rebinding) when it connects. It also proves that a forged X-Forwarded-For never reaches Bifrost.

/var/lib/bifrost/data holds the SQLite configuration store (your provider API keys) and the SQLite log store (the prompts and completions of every request). Only the bifrost user can read it:

sudo stat -c '%a %U:%G' /var/lib/bifrost/data

700 bifrost:bifrost

If you do not want prompts and completions kept, turn content logging off or shorten the retention in Observability > Logs Settings.

To back up the gateway, stop it and copy the directory, or take an EBS snapshot of the instance:

sudo systemctl stop bifrost
sudo tar czf /root/bifrost-backup-$(date +%F).tar.gz -C /var/lib/bifrost data
sudo systemctl start bifrost

Every dependency compiled into the binary was enumerated and licence-checked at build time, and the inventory ships with the image. They are all permissive (MIT, Apache-2.0, BSD, ISC, MPL-2.0). There is no AGPL, SSPL, Business Source, Elastic Licence, Commons Clause or non-commercial component.

The binary carries the upstream commit it was built from:

head -8 /usr/share/bifrost/dependency-licences.txt awk -F'\t' '$1=="go"||$1=="npm"{print $4}' /usr/share/bifrost/dependency-licences.txt | sort | uniq -c | sort -rn | head -6 LC_ALL=C grep -a -o 'vcs\.revision=[0-9a-f]\{40\}' /usr/local/bin/bifrost-http | head -1

# Bifrost appliance — dependency licence inventory (sac)
#
# Every dependency compiled into /usr/local/bin/bifrost-http.
# Go modules : 225 (read from the shipped binary's build info) # npm packages: 682 (pinned ui/package-lock.json — the UI is # compiled into the same binary) # TOTAL : 907 # 668 MIT 106 Apache-2.0 39 BSD-3-Clause 31 ISC 25 MPL-2.0 16 Apache-2.0,BSD-3-Clause vcs.revision=a15edc24a8656950a10c6c3c60430b913cfb313b