May was the self-service month. The signup flow that was previewed in the April update is now live — studios can register, create an organization, and start running sessions without any manual provisioning on our side. Alongside that, trial quotas landed to manage sandbox access, and a set of admin panel and infrastructure improvements shipped.
Here’s everything that landed.
Self-service signup
New studios can now register directly through the admin panel. The flow handles organization creation, a default API token, node pool assignment, and resource profile configuration — all automatically. No sales call, no manual provisioning steps.
Authentication runs through Auth0, supporting both email/password and social login providers. Email verification is enforced before access is granted. Studios that sign up via a social provider (Google, GitHub) skip the email verification step since the provider has already confirmed the address.
The registration flow also provisions a welcome email with credentials via AWS SES, replacing the previous manual onboarding process.
Trial quotas
Registered studios now receive a time-limited trial with a fixed number of session minutes. The trial quota is visible directly in the admin panel navigation bar — a popover shows remaining time and updates in real time as sessions consume minutes.
Trial organizations are automatically assigned a constrained resource profile to prevent runaway usage. When a studio is ready to move to production, a “Go to Production” dialog guides them through the transition, with clear messaging about what changes and what they need to do next.
On the backend, trial quota validation is merged into the container reservation path using transaction-level advisory locks, ensuring quota checks and session starts are atomic — no race conditions, no over-provisioning.
Account linking
Studios that initially registered with email/password can now link their account to a social identity (or vice versa). This prevents the common problem of users creating duplicate accounts across different login methods.
The linking flow detects when an Auth0 identity matches an existing account and prompts the user to merge rather than creating a new one. The backend resolves email addresses from Auth0 tokens or the userinfo endpoint, with normalization to handle case differences.
OOM and exit code visibility
The container detail page now displays exit codes and OOM killed indicators. When a game server container is terminated by the kernel for exceeding its memory limit, the admin panel shows this clearly instead of a generic “stopped” status.
This has been a frequent support question — “why did my container stop?” Now the answer is visible without digging through logs.
TTL display on container details
Container TTL (time-to-live) values are now shown on the container detail page. If a session was started with a TTL, you can see exactly when it’s set to expire. Previously this was only visible through the API.
Smaller changes
Session filtering and auto-refresh. The sessions table now supports filtering by application name, region, and node pool. Auto-refresh keeps the list current without manual reloading.
Registry name display. The application detail form now shows the human-readable registry name instead of a raw ID, making it easier to verify which registry an application is connected to.
Permission refinements. Organization-based access control has been tightened across application, contract, node, and port binding controllers. Non-super-admin users are now properly restricted to their own organization’s resources.
Search and table improvements. GenericTable received an overhaul — search is faster, loading states are more responsive, and pagination handles edge cases more gracefully.
Legal pages. Terms of Service and Privacy Policy are now accessible directly within the admin panel, linked from the footer.
409 Conflict for edge cases. The orchestrator now returns a proper 409 Conflict when a container start is requested for a node that’s been removed but still has a stale container reference — instead of failing with an opaque error.
Moby client upgrade. The deprecated Docker dependency has been replaced with the most recent Moby client version, resolving a set of compile-time warnings and keeping the container runtime integration current.
What’s coming next
The self-service flow is live but there’s more to do. Next month: onboarding tutorials to guide first-time users through creating an application, pushing an image, and starting their first session. The warm pool management interface is also getting attention, and session-based autoscaling is progressing toward its first production deployment.
Questions about any of these changes? See the admin panel docs or reach out directly.