September brought a major expansion to the public API surface and a long-requested infrastructure feature. Session API v1.2.1 lands with scoped token delegation, session filtering for backfill, live log access, artifact retrieval, and full application management via API — replacing the previous requirement to use the admin panel for many of those operations. Alongside that, automatic S3 log uploads are now available: every container that stops can write its full log output to your own S3-compatible bucket.
Here’s everything that landed.
Session API v1.2.1
The original API surface was deliberately minimal — start a session, stop it, check available locations. That’s enough to get a game running, but not enough to build a production backend on. v1.2.1 closes most of the remaining gaps.
Scoped token delegation — POST /token
API tokens can now issue scoped sub-tokens at runtime. You pass your master token, a list of scopes, and an expiry duration; you get back a token that can only do what you asked for, and only inherits scopes your calling token already holds — no escalation possible.
This matters for any multi-component architecture. Your matchmaker holds a long-lived token with broad scopes; your game client gets a short-lived session:read-only token good for 10 minutes so it can poll state without touching anything destructive. Your CI pipeline gets an application:write token scoped to the deploy job, which expires when the job finishes.
Available scopes include session:start, session:stop, session:read, logs:read, artifact:read, application:read, application:write, and token:write.
Session filtering — GET /session
The list endpoint now accepts query parameters. The most operationally significant are the playerCount filters, which exist specifically to support backfill:
GET /session?location=europe&image=my-game&playerCount[lt]=8
Returns every session in Europe with fewer than 8 players — enough to route new players into existing lobbies rather than always starting cold. You can also filter by location, image, tag, host IP, and arbitrary label key/value pairs set at session start time.
Application management via API
Creating and updating application registrations — the configuration that maps a Docker image to its resource limits, region availability, and port bindings — previously required the admin panel. Five new endpoints change that: POST /application, PUT /application/{name}, GET /application, POST /application/{name}/tags, and GET /application/{name}/tags/available.
The most useful of these for teams with any kind of CI/CD pipeline is POST /application/{name}/tags: call it after a successful image push to pre-load the new tag across the Gameye fleet. By the time QA finishes, the image is already distributed and the first session starts without a cold-pull delay.
Other additions
GET /session/{id} returns full session state including current container status (running, draining, server_unreachable, etc.) and the tracked player list — useful for health checks and session watchdog logic.
GET /region returns the complete list of region names available to your account, so you can drive region selection dynamically rather than hardcoding strings.
POST /session gets two corrections: ttl is a duration string ("2h", "30m") not an integer, and external_id is now documented — it lets you attach your own identifier (match ID, lobby reference) to a session so Gameye sessions map cleanly back to your own records.
For the full walkthrough with code examples for every endpoint, see the Session API v1.2.1 release post.
Automatic S3 log uploads
Every game server session can now automatically upload its log output to your S3-compatible bucket when the container stops.
The agent gzip-compresses the container’s stdout and stderr and uploads it via multipart upload. The file lands at {container-name}/logs/logs.txt in whatever bucket you configure. No code changes to your server binary are required — configuration is entirely on the application side.
Works with any S3-compatible provider. AWS S3, Cloudflare R2, MinIO, Backblaze B2, or any provider that speaks the S3 API. For studios already on R2, logs can stay co-located with other data without routing through AWS.
Setup is two steps. First, store your credentials via POST /v2/secrets/s3 — they’re encrypted at rest with AES-256-GCM and never returned after creation. Then set s3BucketName, s3Region, and s3CredentialsId on your application in the admin panel or via PUT /application/{name}. Sessions started after that change write logs to your bucket automatically.
Reliability: The agent checks for an existing log file before uploading (HeadObject), so a node reboot doesn’t produce duplicate files. Incomplete multipart uploads from a previous run are aborted on startup to keep storage costs clean.
The S3 log uploads docs cover IAM policy, Cloudflare R2 specifics, and troubleshooting.
Smaller changes
GHCR support foundations. Registry authentication was refactored to support private GitHub Container Registry images alongside Docker Hub. GHCR pull support is in place for organizations that host images there.
API token expiry fix. A timezone handling bug in token expiry validation was fixed — tokens were being rejected as expired in some timezone offsets when they should still have been valid.
Reserved pricing update. The reserved capacity rate is now $0.035/vCPU-hr, with the 4 GB RAM tier at $0.042/vCPU-hr. See the pricing page for current rates.
Security headers. Missing response headers (X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy) were added to SSR Worker responses.
What’s coming next
Billing payment flows and subscription management are the primary focus — the billing backend that landed in June needs its front-end counterpart so studios can self-serve upgrades. TLS, which shipped behind a feature flag in June, continues validation and is on track to become the default for new session configurations.
Questions about any of these changes? See the docs or reach out directly.
More platform updates: ← June 2026