Server

Authentication, rate limiting, CORS, routing, and trace coordination — automatically applied as the entrypoint for every request.

Overview

The flux-server binary sits in front of your deployed functions. It acts as the orchestrator and entrypoint. It handles every concern that should be resolved before your business logic runs — authentication, routing, rate limiting, CORS — and stamps every request with a unique trace ID that flows through the system.

You don't configure the routing manually. Routes are derived from your flux.json files. Auth is enforced using your project API keys. CORS is handled automatically. Nothing to set up.

Authentication

Every request to a deployed function must carry a valid credential. The server supports two modes:

Project API keys

The primary authentication method for server-to-server and client-to-server calls. Generate keys in the dashboard or CLI.

# Using a project API key in the Authorization header
$ curl https://localhost:4000/create_order \
    -H "Authorization: Bearer flx_live_abc123..." \
    -H "Content-Type: application/json" \
    -d '{"userId": "u_881", "total": 49.99}'

Managing API keys

# Create a new API key for your project
$ flux api-keys create --name "production-server"
flx_live_abc123...xyz789

# List all keys
$ flux api-keys list

  production-server   flx_live_abc1...   created 2 days ago
  staging             flx_test_xyz9...   created 1 week ago

# Revoke a key
$ flux api-keys revoke production-server

Routing

The Server builds its routing table from the flux.json files of all deployed functions in your project. Each function declares its own route and HTTP method.

// functions/create_order/flux.json
{
  "name": "create_order",
  "runtime": "deno",
  "route": "/create_order",
  "method": "POST"
}

After running flux deploy, this function is reachable at:

POST https://localhost:4000/create_order

Route configuration fields

Rate limiting

The Server enforces per-project rate limits to protect your functions from traffic spikes and abuse. Limits are applied per API key.

When a rate limit is exceeded, the server returns:

HTTP 429 Too Many Requests
Retry-After: 15

CORS

CORS is handled automatically at the server level. By default, all origins are allowed for GET requests. For POST/PUT/DELETE, restrict origins in your project settings.

To configure allowed origins:

# Allow only your frontend domain
$ flux project update --cors-origin https://your-app.com

Request tracing

The Server stamps every inbound request with:

• x-request-id — a unique ID for the request, propagated to the runtime
• Server auth result, rate-limit check outcome, and routing decision are all recorded as the first span in the trace

The trace ID is also returned in the HTTP response:

HTTP/2 200
x-request-id: 9c3e7f1a
content-type: application/json

{"orderId": "ord_xyz"}

Use this ID with flux trace:

$ flux trace 9c3e7f1a

Middleware pipeline

The Server processes middleware in a fixed order. Each step either passes the request forward or returns an error response:

1. API key authentication — validates the Authorization header
2. Rate limit check — counts against the key's quota
3. Route lookup — matches the path + method to a deployed function
4. CORS headers — applies configured origin allowlist
5. x-request-id injection — stamps a unique trace ID
6. Function dispatch — forwards to the runtime or queue (for async)

Error responses

← Architecture Next: Secrets →