Auth
Keep API keys on trusted servers
Tileflow separates write access from browser access. Keep API keys in the CLI, CI, or server routes. Use allowedOrigins to reduce unauthorized browser embedding, not to make public map data private.
# Approved accounts can authorize the CLI in the dashboard.
tileflow login
# Or store an existing project key manually.
tileflow login --manual
# CI or headless machines
TILEFLOW_API_KEY=tf_live_... tileflow deploy
# Confirm the saved credential and scopes
tileflow whoamiModes
Pick the credential by runtime
The browser should not hold project API keys. Use the CLI for developer machines, bearer keys for trusted servers, and origin restrictions for deployed frontends.
No account or API keyFramework adapters and tileflow dev resolve local styles from the dev server.
Saved pre-provisioned key or TILEFLOW_API_KEYDeploy styles, manage tilesets, and inspect project status.
Bearer API key in Authorization headerCreate static maps, precache images, or call write APIs from CI.
allowedOrigins embedding allowlistReduce unauthorized browser embedding; this is not authentication or data privacy.
Permissions
Two clear levels
Choose full project access for CLI and CI, or restrict a server key to static map rendering. Tileflow stores every key hashed and enforces its permission on each request.
Full accessPublish styles, manage tilesets, inspect project status, and render static maps.Static maps onlyCreate and precache static map images without changing styles or tilesets.Origins
Restrict production map loads in config
allowedOrigins belongs on map config because the map is the browser-facing hotlink-control contract. Local development is allowed, while deployed websites must match the list. Origin headers are not credentials and hosted map data remains public to non-browser clients.
tileflow login opens the approved dashboard device flow. Use tileflow login --manual only when you already have a project key./v1/me and tileflow whoami confirm project ID, key prefix, and scopes.