Skip to content

Latest commit

 

History

History
753 lines (526 loc) · 27.2 KB

Deployment guide.md

File metadata and controls

753 lines (526 loc) · 27.2 KB

Easy Guide to Deploying LLM-API-Key-Proxy on Render

This guide walks you through deploying the LLM-API-Key-Proxy as a hosted service on Render.com. The project provides a universal, OpenAI-compatible API endpoint for all your LLM providers (like Gemini or OpenAI), powered by an intelligent key management library. It's perfect for integrating with platforms like JanitorAI, where you can use it as a custom proxy for highly available and resilient chats.

The process is beginner-friendly and takes about 15-30 minutes. We'll use Render's free tier (with limitations like sleep after 15 minutes of inactivity) and upload your .env file as a secret for easy key management—no manual entry of variables required.

Prerequisites

  • A free Render.com account (sign up at render.com).
  • A GitHub account (for forking the repo).
  • Basic terminal access (e.g., Command Prompt, Terminal, or Git Bash).
  • API keys from LLM providers (e.g., Gemini, OpenAI—get them from their dashboards). For details on supported providers and how to format their keys (e.g., API key naming conventions), refer to the LiteLLM Providers Documentation.

Note: You don't need Python installed for initial testing—use the pre-compiled Windows EXE from the repo's releases for a quick local trial.

Step 1: Test Locally with the Compiled EXE (No Python Required)

Before deploying, try the proxy locally to ensure your keys work. This uses a pre-built executable that's easy to set up.

  1. Go to the repo's GitHub Releases page.
  2. Download the latest release ZIP file (e.g., for Windows).
  3. Unzip the file.
  4. Double-click setup_env.bat. A window will open—follow the prompts to add your PROXY_API_KEY (a strong secret you create) and provider keys. Use the LiteLLM Providers Documentation for guidance on key formats (e.g., GEMINI_API_KEY_1="your-key").
  5. Double-click proxy_app.exe to start the proxy. It runs at http://127.0.0.1:8000—visit in a browser to confirm "API Key Proxy is running".
  6. Test with curl (replace with your PROXY_API_KEY):
curl -X POST http://127.0.0.1:8000/v1/chat/completions -H "Content-Type: application/json" -H "Authorization: Bearer your-proxy-key" -d '{"model": "gemini/gemini-2.5-flash", "messages": [{"role": "user", "content": "What is the capital of France?"}]}'

- Expected: A JSON response with the answer (e.g., "Paris").

If it works, you're ready to deploy. If not, double-check your keys against LiteLLM docs.

Step 2: Fork and Prepare the Repository

  1. Go to the original repo: https://github.com/Mirrowel/LLM-API-Key-Proxy.
  2. Click Fork in the top-right to create your own copy (this lets you make changes if needed).
  3. Clone your forked repo locally:
git clone https://github.com/YOUR-USERNAME/LLM-API-Key-Proxy.git
cd LLM-API-Key-Proxy

Step 3: Assemble Your .env File

The proxy uses a .env file to store your API keys securely. We'll create this based on the repo's documentation.

  1. In your cloned repo, copy the example: copy .env.example .env (Windows) or cp .env.example .env (macOS/Linux).
  2. Open .env in a text editor (e.g., Notepad or VS Code).
  3. Add your keys following the format from the repo's README and LiteLLM Providers Documentation:
    • PROXY_API_KEY: Create a strong, unique secret (e.g., "my-super-secret-proxy-key"). This authenticates requests to your proxy.
    • Provider Keys: Add keys for your chosen providers. You can add multiple per provider (e.g., _1, _2) for rotation.

Example .env (customize with your real keys):

# Your proxy's authentication key (invent a strong one)
PROXY_API_KEY="my-super-secret-proxy-key"

# Provider API keys (get from provider dashboards; see LiteLLM docs for formats)
GEMINI_API_KEY_1="your-gemini-key-here"
GEMINI_API_KEY_2="another-gemini-key"

OPENROUTER_API_KEY_1="your-openrouter-key"

- Supported providers: Check LiteLLM docs for a full list and specifics (e.g., GEMINI, OPENROUTER, NVIDIA_NIM).
- Tip: Start with 1-2 providers to test. Don't share this file publicly!

Advanced: Stateless Deployment for OAuth Providers (Gemini CLI, Qwen, iFlow)

If you are using providers that require complex OAuth files (like Gemini CLI, Qwen Code, or iFlow), you don't need to upload the JSON files manually. The proxy includes a tool to "export" these credentials into environment variables.

  1. Run the credential tool locally: python -m rotator_library.credential_tool
  2. Select the "Export ... to .env" option for your provider.
  3. The tool will generate a file (e.g., gemini_cli_user_at_gmail.env) containing variables like GEMINI_CLI_ACCESS_TOKEN, GEMINI_CLI_REFRESH_TOKEN, etc.
  4. Copy the contents of this file and paste them directly into your .env file or Render's "Environment Variables" section.
  5. The proxy will automatically detect and use these variables—no file upload required!

Advanced: Antigravity OAuth Provider

The Antigravity provider requires OAuth2 authentication similar to Gemini CLI. It provides access to:

  • Gemini 2.5 models (Pro/Flash)
  • Gemini 3 models (Pro/Image-preview) - requires paid-tier Google Cloud project
  • Claude Sonnet 4.5 via Google's Antigravity proxy

Setting up Antigravity locally:

  1. Run the credential tool: python -m rotator_library.credential_tool
  2. Select "Add OAuth Credential" and choose "Antigravity"
  3. Complete the OAuth flow in your browser
  4. The credential is saved to oauth_creds/antigravity_oauth_1.json

Exporting for stateless deployment:

  1. Run: python -m rotator_library.credential_tool
  2. Select "Export Antigravity to .env"
  3. Copy the generated environment variables to your deployment platform: 
    ANTIGRAVITY_ACCESS_TOKEN="..."
ANTIGRAVITY_REFRESH_TOKEN="..."
ANTIGRAVITY_EXPIRY_DATE="..."
ANTIGRAVITY_EMAIL="your-email@gmail.com"

Important Notes:

  • Antigravity uses Google OAuth with additional scopes for cloud platform access
  • Gemini 3 models require a paid-tier Google Cloud project (free tier will fail)
  • The provider automatically handles thought signature caching for multi-turn conversations
  • Tool hallucination prevention is enabled by default for Gemini 3 models
  1. Save the file. (We'll upload it to Render in Step 5.)

Step 4: Create a New Web Service on Render

  1. Log in to render.com and go to your Dashboard.
  2. Click New > Web Service.
  3. Choose Build and deploy from a Git repository > Next.
  4. Connect your GitHub account and select your forked repo.
  5. In the setup form:
    • Name: Something like "llm-api-key-proxy".
    • Region: Choose one close to you (e.g., Oregon for US West).
    • Branch: "main" (or your default).
    • Runtime: Python 3.
    • Build Command: pip install -r requirements.txt.
    • Start Command: uvicorn src.proxy_app.main:app --host 0.0.0.0 --port $PORT.
    • Instance Type: Free (for testing; upgrade later for always-on service).
  6. Click Create Web Service. Render will build and deploy—watch the progress in the Events tab.

Step 5: Upload .env as a Secret File

Render mounts secret files securely at runtime, making your .env available to the app without exposing it.

  1. In your new service's Dashboard, go to Environment > Secret Files.
  2. Click Add Secret File.
  3. File Path: Don't change. Keep it as root directory of the repo.
  4. Contents: Upload the .env file you created previously.
  5. Save. This injects the file for the app to load via dotenv (already in the code).
  6. Trigger a redeploy: Go to Deploy > Manual Deploy > Deploy HEAD (or push a small change to your repo).

Your keys are now loaded automatically!

Step 6: Test Your Deployed Proxy

  1. Note your service URL: It's in the Dashboard (e.g., https://llm-api-key-proxy.onrender.com).
  2. Test with curl (replace with your PROXY_API_KEY):
curl -X POST https://your-service.onrender.com/v1/chat/completions -H "Content-Type: application/json" -H "Authorization: Bearer your-proxy-key" -d '{"model": "gemini/gemini-2.5-flash", "messages": [{"role": "user", "content": "What is the capital of France?"}]}'

- Expected: A JSON response with the answer (e.g., "Paris").
  1. Check logs in Render's Dashboard for startup messages (e.g., "RotatingClient initialized").

Step 7: Integrate with JanitorAI

  1. Log in to janitorai.com and go to API settings (usually in a chat or account menu).
  2. Select "Proxy" mode.
  3. API URL: https://your-service.onrender.com/v1.
  4. API Key: Your PROXY_API_KEY (from .env).
  5. Model: Format as "provider/model" (e.g., "gemini/gemini-2.5-flash"; check LiteLLM docs for options).
  6. Save and test a chat—messages should route through your proxy.

Troubleshooting

  • Build Fails: Check Render logs for missing dependencies—ensure requirements.txt is up to date.
  • 401 Unauthorized: Verify your PROXY_API_KEY matches exactly (case-sensitive) and includes "Bearer " in requests. Or you have no keys for the provider/model added that you are trying to use.
  • 405 on OPTIONS: If CORS issues arise, add the middleware from Step 3 and redeploy.
  • Service Sleeps: Free tier sleeps after inactivity—first requests may delay.
  • Provider Key Issues: Double-check formats in LiteLLM Providers Documentation.
  • More Help: Check Render docs or the repo's README. If stuck, share error logs.

That is it.

Appendix: Deploying with Docker

Docker provides a consistent, portable deployment option for any platform. The proxy image is automatically built and published to GitHub Container Registry (GHCR) on every push to main or dev branches.

Quick Start with Docker Compose

This is the fastest way to deploy the proxy using Docker.

  1. Create your configuration files:
# Clone the repo (or just download docker-compose.yml and .env.example)
git clone https://github.com/Mirrowel/LLM-API-Key-Proxy.git
cd LLM-API-Key-Proxy

# Create your .env file
cp .env.example .env
nano .env  # Add your PROXY_API_KEY and provider keys

# Create key_usage.json file (required before first run)
touch key_usage.json

Important: You must create key_usage.json before running Docker Compose. If this file doesn't exist on the host, Docker will create it as a directory instead of a file, causing the container to fail.

  1. Start the proxy:
docker compose up -d
  1. Verify it's running:
# Check container status
docker compose ps

# View logs
docker compose logs -f

# Test the endpoint
curl http://localhost:8000/

Manual Docker Run

If you prefer not to use Docker Compose:

# Create necessary directories and files
mkdir -p oauth_creds logs
touch key_usage.json

# Run the container
docker run -d \
  --name llm-api-proxy \
  --restart unless-stopped \
  -p 8000:8000 \
  -v $(pwd)/.env:/app/.env:ro \
  -v $(pwd)/oauth_creds:/app/oauth_creds \
  -v $(pwd)/logs:/app/logs \
  -v $(pwd)/key_usage.json:/app/key_usage.json \
  -e SKIP_OAUTH_INIT_CHECK=true \
  -e PYTHONUNBUFFERED=1 \
  ghcr.io/mirrowel/llm-api-key-proxy:latest

Available Image Tags

Tag Description Use Case
latest Latest stable build from main branch Production
dev-latest Latest build from dev branch Testing new features
YYYYMMDD-HHMMSS-<sha> Specific version with timestamp and commit hash Pinned deployments

Example using a specific version:

docker pull ghcr.io/mirrowel/llm-api-key-proxy:20250106-143022-abc1234

Volume Mounts Explained

Host Path Container Path Purpose Mode
./.env /app/.env Configuration and API keys Read-only (:ro)
./oauth_creds/ /app/oauth_creds/ OAuth credential JSON files Read-write
./logs/ /app/logs/ Request logs and detailed logging Read-write
./key_usage.json /app/key_usage.json Usage statistics persistence Read-write

Setting Up OAuth Providers with Docker

OAuth providers (Antigravity, Gemini CLI, Qwen Code, iFlow) require interactive browser authentication. Since Docker containers run headless, you must authenticate outside the container first.

Option 1: Authenticate Locally, Mount Credentials (Recommended)

  1. Set up the project locally:
git clone https://github.com/Mirrowel/LLM-API-Key-Proxy.git
cd LLM-API-Key-Proxy
pip install -r requirements.txt
  1. Run the credential tool and complete OAuth flows:
python -m rotator_library.credential_tool
# Select "Add OAuth Credential" → Choose provider
# Complete authentication in browser
  1. Deploy with Docker, mounting the oauth_creds directory:
docker compose up -d
# The oauth_creds/ directory is automatically mounted

Option 2: Export Credentials to Environment Variables

For truly stateless deployments (no mounted credential files):

  1. Complete OAuth locally as above

  2. Export credentials to environment variables:

python -m rotator_library.credential_tool
# Select "Export [Provider] to .env"
  1. Add the exported variables to your .env file:
# Example for Antigravity
ANTIGRAVITY_ACCESS_TOKEN="ya29.a0AfB_byD..."
ANTIGRAVITY_REFRESH_TOKEN="1//0gL6dK9..."
ANTIGRAVITY_EXPIRY_DATE="1735901234567"
ANTIGRAVITY_EMAIL="user@gmail.com"
ANTIGRAVITY_CLIENT_ID="1071006060591-..."
ANTIGRAVITY_CLIENT_SECRET="GOCSPX-..."
  1. Deploy with Docker:
docker compose up -d
# Credentials are loaded from .env, no oauth_creds mount needed

Development: Building Locally

For development or customization, use the development compose file:

# Build and run from local source
docker compose -f docker-compose.dev.yml up -d --build

# Rebuild after code changes
docker compose -f docker-compose.dev.yml up -d --build --force-recreate

Container Management

# Stop the proxy
docker compose down

# Restart the proxy
docker compose restart

# View real-time logs
docker compose logs -f

# Check container resource usage
docker stats llm-api-proxy

# Update to latest image
docker compose pull
docker compose up -d

Docker on Different Platforms

The image is built for both linux/amd64 and linux/arm64 architectures, so it works on:

  • Linux servers (x86_64, ARM64)
  • macOS (Intel and Apple Silicon)
  • Windows with WSL2/Docker Desktop
  • Raspberry Pi 4+ (ARM64)

Troubleshooting Docker Deployment

Issue Solution
Container exits immediately Check logs: docker compose logs — likely missing .env or invalid config
Permission denied on volumes Ensure directories exist and have correct permissions: mkdir -p oauth_creds logs && chmod 755 oauth_creds logs
OAuth credentials not loading Verify oauth_creds/ is mounted and contains valid JSON files, or check environment variables are set
Port already in use Change the port mapping: -p 9000:8000 or edit docker-compose.yml
Image not updating Force pull: docker compose pull && docker compose up -d

Appendix: Deploying to a Custom VPS

If you're deploying the proxy to a custom VPS (DigitalOcean, AWS EC2, Linode, etc.) instead of Render.com, you'll encounter special considerations when setting up OAuth providers (Antigravity, Gemini CLI, iFlow). This section covers the professional deployment workflow.

Understanding the OAuth Callback Problem

OAuth providers like Antigravity, Gemini CLI, and iFlow require an interactive authentication flow that:

  1. Opens a browser for you to log in
  2. Redirects back to a local callback server running on specific ports
  3. Receives an authorization code to exchange for tokens

The callback servers bind to localhost on these ports:

Provider Port Notes
Antigravity 51121 Google OAuth with extended scopes
Gemini CLI 8085 Google OAuth for Gemini API
iFlow 11451 Authorization Code flow with API key fetch
Qwen Code N/A Uses Device Code flow - works on remote VPS ✅

The Issue: When running on a remote VPS, your local browser cannot reach http://localhost:51121 (or other callback ports) on the remote server, causing authentication to fail with a "connection refused" error.

Recommended Deployment Workflow

There are three professional approaches to handle OAuth authentication for VPS deployment, listed from most recommended to least:

Option 1: Authenticate Locally, Deploy Credentials (RECOMMENDED)

This is the cleanest and most secure approach. Complete OAuth flows on your local machine, export to environment variables, then deploy.

Step 1: Clone and Set Up Locally

# On your local development machine
git clone https://github.com/YOUR-USERNAME/LLM-API-Key-Proxy.git
cd LLM-API-Key-Proxy

# Install dependencies
pip install -r requirements.txt

Step 2: Run OAuth Authentication Locally

# Start the credential tool
python -m rotator_library.credential_tool

Select "Add OAuth Credential" and choose your provider:

  • Antigravity
  • Gemini CLI
  • iFlow
  • Qwen Code (works directly on VPS, but can authenticate locally too)

The tool will:

  1. Open your browser automatically
  2. Start a local callback server
  3. Complete the OAuth flow
  4. Save credentials to oauth_creds/<provider>_oauth_N.json

Step 3: Export Credentials to Environment Variables

Still in the credential tool, select the export option for each provider:

  • "Export Antigravity to .env"
  • "Export Gemini CLI to .env"
  • "Export iFlow to .env"
  • "Export Qwen Code to .env"

The tool generates a .env file snippet like:

# Antigravity OAuth Credentials
ANTIGRAVITY_ACCESS_TOKEN="ya29.a0AfB_byD..."
ANTIGRAVITY_REFRESH_TOKEN="1//0gL6dK9..."
ANTIGRAVITY_EXPIRY_DATE="1735901234567"
ANTIGRAVITY_EMAIL="user@gmail.com"
ANTIGRAVITY_CLIENT_ID="1071006060591-..."
ANTIGRAVITY_CLIENT_SECRET="GOCSPX-..."
ANTIGRAVITY_TOKEN_URI="https://oauth2.googleapis.com/token"
ANTIGRAVITY_UNIVERSE_DOMAIN="googleapis.com"

Copy these variables to a file (e.g., oauth_credentials.env).

Step 4: Deploy to VPS

Method A: Using Environment Variables (Recommended)

# On your VPS
cd /path/to/LLM-API-Key-Proxy

# Create or edit .env file
nano .env

# Paste the exported environment variables
# Also add your PROXY_API_KEY and other provider keys

# Start the proxy
uvicorn src.proxy_app.main:app --host 0.0.0.0 --port 8000

Method B: Upload Credential Files

# On your local machine - copy credential files to VPS
scp -r oauth_creds/ user@your-vps-ip:/path/to/LLM-API-Key-Proxy/

# On VPS - verify files exist
ls -la oauth_creds/

# Start the proxy
uvicorn src.proxy_app.main:app --host 0.0.0.0 --port 8000

Note: Environment variables are preferred for production deployments (more secure, easier to manage, works with container orchestration).

Option 2: SSH Port Forwarding (For Direct VPS Authentication)

If you need to authenticate directly on the VPS (e.g., you don't have a local development environment), use SSH port forwarding to create secure tunnels.

How It Works

SSH tunnels forward ports from your local machine to the remote VPS, allowing your local browser to reach the callback servers.

Step-by-Step Process

Step 1: Create SSH Tunnels

From your local machine, open a terminal and run:

# Forward all OAuth callback ports at once
ssh -L 51121:localhost:51121 -L 8085:localhost:8085 -L 11451:localhost:11451 user@your-vps-ip

# Alternative: Forward ports individually as needed
ssh -L 51121:localhost:51121 user@your-vps-ip  # For Antigravity
ssh -L 8085:localhost:8085 user@your-vps-ip    # For Gemini CLI
ssh -L 11451:localhost:11451 user@your-vps-ip  # For iFlow

Keep this SSH session open during the entire authentication process.

Step 2: Run Credential Tool on VPS

In the same SSH terminal (or open a new SSH connection):

cd /path/to/LLM-API-Key-Proxy

# Ensure Python dependencies are installed
pip install -r requirements.txt

# Run the credential tool
python -m rotator_library.credential_tool

Step 3: Complete OAuth Flow

  1. Select "Add OAuth Credential" → Choose your provider
  2. The tool displays an authorization URL
  3. Click the URL in your local browser (works because of the SSH tunnel!)
  4. Complete the authentication flow
  5. The browser redirects to localhost:<port> - this now routes through the tunnel to your VPS
  6. Credentials are saved to oauth_creds/ on the VPS

Step 4: Export to Environment Variables

Still in the credential tool:

  1. Select the export option for each provider
  2. Copy the generated environment variables
  3. Add them to /path/to/LLM-API-Key-Proxy/.env on your VPS

Step 5: Close Tunnels and Deploy

# Exit the SSH session with tunnels (Ctrl+D or type 'exit')
# Tunnels are no longer needed

# Start the proxy on VPS (in a screen/tmux session or as a service)
uvicorn src.proxy_app.main:app --host 0.0.0.0 --port 8000

Option 3: Copy Credential Files to VPS

If you've already authenticated locally and have credential files, you can copy them directly.

Copy OAuth Credential Files

# From your local machine
scp -r oauth_creds/ user@your-vps-ip:/path/to/LLM-API-Key-Proxy/

# Verify on VPS
ssh user@your-vps-ip
ls -la /path/to/LLM-API-Key-Proxy/oauth_creds/

Expected files:

  • antigravity_oauth_1.json
  • gemini_cli_oauth_1.json
  • iflow_oauth_1.json
  • qwen_code_oauth_1.json

Configure .env to Use Credential Files

On your VPS, edit .env:

# Option A: Use credential files directly (not recommended for production)
# No special configuration needed - the proxy auto-detects oauth_creds/ folder

# Option B: Export to environment variables (recommended)
# Run credential tool and export each provider to .env

Environment Variables vs. Credential Files

Aspect Environment Variables Credential Files
Security ✅ More secure (no files on disk) ⚠️ Files readable if server compromised
Container-Friendly ✅ Perfect for Docker/K8s ❌ Requires volume mounts
Ease of Rotation ✅ Update .env and restart ⚠️ Need to regenerate JSON files
Backup/Version Control ✅ Easy to manage with secrets managers ❌ Binary files, harder to manage
Auto-Refresh ✅ Uses refresh tokens ✅ Uses refresh tokens
Recommended For Production deployments Local development / testing

Best Practice: Always export to environment variables for VPS/cloud deployments.

Production Deployment Checklist

Security Best Practices

  • Never commit .env or oauth_creds/ to version control
  • Use environment variables instead of credential files in production
  • Secure your VPS firewall - do not open OAuth callback ports (51121, 8085, 11451) to public internet
  • Use SSH port forwarding only during initial authentication
  • Rotate credentials regularly using the credential tool's export feature
  • Set file permissions on .env: chmod 600 .env

Firewall Configuration

OAuth callback ports should never be publicly exposed:

# ❌ DO NOT DO THIS - keeps ports closed
# sudo ufw allow 51121/tcp
# sudo ufw allow 8085/tcp
# sudo ufw allow 11451/tcp

# ✅ Only open your proxy API port
sudo ufw allow 8000/tcp

# Check firewall status
sudo ufw status

The SSH tunnel method works without opening these ports because traffic routes through the SSH connection (port 22).

Running as a Service

Create a systemd service file on your VPS:

# Create service file
sudo nano /etc/systemd/system/llm-proxy.service
[Unit]
Description=LLM API Key Proxy
After=network.target

[Service]
Type=simple
User=your-username
WorkingDirectory=/path/to/LLM-API-Key-Proxy
Environment="PATH=/path/to/python/bin"
ExecStart=/path/to/python/bin/uvicorn src.proxy_app.main:app --host 0.0.0.0 --port 8000
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target
# Enable and start the service
sudo systemctl daemon-reload
sudo systemctl enable llm-proxy
sudo systemctl start llm-proxy

# Check status
sudo systemctl status llm-proxy

# View logs
sudo journalctl -u llm-proxy -f

Troubleshooting VPS Deployment

"localhost:51121 connection refused" Error

Cause: Trying to authenticate directly on VPS without SSH tunnel.

Solution: Use Option 1 (authenticate locally) or Option 2 (SSH port forwarding).

OAuth Credentials Not Loading

# Check if environment variables are set
printenv | grep -E '(ANTIGRAVITY|GEMINI_CLI|IFLOW|QWEN_CODE)'

# Verify .env file exists and is readable
ls -la .env
cat .env | grep -E '(ANTIGRAVITY|GEMINI_CLI|IFLOW|QWEN_CODE)'

# Check credential files if using file-based approach
ls -la oauth_creds/

Token Refresh Failing

The proxy automatically refreshes tokens using refresh tokens. If refresh fails:

  1. Re-authenticate: Run credential tool again and export new credentials
  2. Check token expiry: Some providers require periodic re-authentication
  3. Verify credentials: Ensure REFRESH_TOKEN is present in environment variables

Permission Denied on .env

# Set correct permissions
chmod 600 .env
chown your-username:your-username .env

Summary: VPS Deployment Best Practices

  1. Authenticate locally on your development machine (easiest, most secure)
  2. Export to environment variables using the credential tool's built-in export feature
  3. Deploy to VPS by adding environment variables to .env
  4. Never open OAuth callback ports to the public internet
  5. Use SSH port forwarding only if you must authenticate directly on VPS
  6. Run as a systemd service for production reliability
  7. Monitor logs for authentication errors and token refresh issues

This approach ensures secure, production-ready deployment while maintaining the convenience of OAuth authentication.