The most substantive document from Marketing this period is a detailed POC evaluation comparing Customer.io and Braze, authored by Krisztian Paczolay. The evaluation frames the decision around two central questions: can the CRM team build, test, and deploy complex multi-channel journeys with high autonomy, and how does each platform handle the operational requirements of a fast-moving marketing function. Both tools are in active testing; the document captures early findings and is marked in progress. The outcome will shape campaign tooling for the foreseeable future, making it one of the more consequential decisions currently in flight.

In the background, two partner giveaways ran in May. Giveaway #69 partnered with Goblin Tech Keys and offered a custom Nitrado keyboard, a 10-slot game server subscription, and a merch package as first prize. Giveaway #70 followed with Windrose x nerdytec, with the Couchmaster Edition and accompanying game keys at the top of the prize list. Both campaigns used nitra.do short links and ran worldwide, which reflects the standard format the team uses for partnership campaigns, keeping logistics consistent while the brand partners vary.

Earlier in the period, Jordan Johnson published two strategic documents in the Marketing space: a Competitor Content Audit surveying the public-facing content of AccelByte, Edgegap, Gameye, Snapser, AWS GameLift, and PlayFab; and a companion GameFabric Technical Content Gaps Audit mapping where GameFabric's current marketing output leaves ground uncovered. Both are positioned as reference inputs for content planning rather than immediate action items. Taken together with the CRM evaluation, they represent a phase of structured assessment in the Marketing function, gathering data before committing to direction.

The Messaging Service V1 spec defines a platform-wide event bus that receives events from producer systems, persists them with 90-day retention, applies permission-based visibility, and surfaces them in the GameFabric UI. The event catalog in scope for V1 covers eleven categories: three security events from SteelShield covering DDoS attack detection, mitigation start, and mitigation end; four infrastructure events tied to Vessel provisioning lifecycle and Armada Set capacity; and three global events covering scheduled maintenance windows, live maintenance, and platform-wide disruptions. Each event specifies its audience targeting, trigger source, and noise-control behavior to prevent flooding under repeated conditions such as provisioning crash loops.

Visibility in V1 is permission-based rather than role-based, matching how GameFabric's access control already functions. A user sees an event only if they hold view permission on the resource it references. Audience targeting is a second layer: user-initiated events route only to the initiating user by default, while global events are org-wide. The spec raises several open questions for resolution before implementation, including how permission cascading works across parent and child resources, and whether traffic anomaly events belong in V1 given their potential noise levels below the attack threshold.

V2, documented as a planned but not committed follow-up, adds a programmatic read interface to the same event stream. The recommended shape is a REST polling API with filters for date range, event type, producer, and resource reference. Webhook-style push delivery is explicitly out of scope, deferred to a separate future Alerting feature. GCAP v0.11.0 released on 26 May, migrating global location management from the GF Bootstrapper into GCAP itself; the release includes a hard dependency requiring all global location data to be entered accurately in GCAP prior to rollout.

The Edgegap battle card is the most operationally significant document added to the Sales space this period. Its core principle is explicit: don't bash Edgegap, win by surfacing fit. The card opens with a fair statement of what Edgegap does well, including their 615-PoP global footprint, self-serve free tier, and developer-friendly Unity and Unreal tooling, before laying out the counter-positioning. The headline credibility anchor is GameFabric's scale: over one billion sessions orchestrated, with 362 million allocated during the Last Epoch 1.0 launch window alone in 14 days, at a sustained rate of 300 allocations per second.

The card identifies five factual inaccuracies in Edgegap's public materials for use when their claims are challenged: the assertion that customers need a full-time infrastructure engineer (disproved by Fenris Corporation's own on-record statement), the claim that no container registry is included (it ships at no extra cost), inaccurate fleet overhead figures, the suggestion that the Allocator is effectively required, and a question on case study verification for the CCP/Fenris matchmaking figure. A don't-say list rounds it out with prohibitions on calling Edgegap unreliable, their pricing opaque, or their PoP count fake.

Three product enablement pages fill out the rest of the activity. Formations & Vessels addresses the deployment model for long-running, named-session games: survival, sandbox, server-browser titles, and community servers where players return to the same server. Scale-to-Zero targets the cost case: when player load drops low enough that bare metal can absorb it all, cloud capacity in lower-priority region types is drained to zero automatically. Dynamic Buffers handles the middle ground, with a single slider from Cost Efficient to Availability managing the buffer around the clock.

The Game Update on 26 May covered a full patch cycle for the Dune: Awakening dedicated server fleet. Danny Messig's operational checklist walked through image pre-pull on both development and production Ansible host groups, revision updates across all battlegroups, database migration pod verification, and player monitoring via Grafana once Funcom announced the maintenance window had ended. The standard pre-maintenance steps included silencing three specific Grafana alerts, Invalid Leader Map, Missing Servers (Diff to Directory), and its critical variant, for a two-hour window. All steps in the checklist show as completed.

A separate database update ran today, 29 May, following a similar checklist pattern. The DB Update covered SQL statement execution across development and production battlegroups, maintenance scheduling via the admin API, and the same Grafana alert silencing pattern, this time for a 30-minute window. Unlike the May 26 game update, the Discord announcements in the DB Update checklist remain unchecked, suggesting this maintenance was handled without prior community notice.

Behind these routine operational updates, a more substantial infrastructure project is under way. Bernhard Sobotzik published a project roadmap for migrating all Linux storage nodes to Ubuntu 24.04 LTS, with a target completion date of 30 November 2026 and an estimated 140 days of PG effort. An accompanying strategy document covers the OS upgrade sequencing and iterative approach. The Dune Backup & Restore documentation was also refreshed this period, keeping cloud backup procedures and post-patch verification steps current alongside the operational runbooks.

The Game Restrictions Guide, published today by Lucca Kaiser, documents the database-driven system that enforces per-game rule limitations via two tables, game_restrictions and game_restriction_values, exposed through Nitrapi. The current primary use case is ARK: Survival Ascended, where specific maps require a minimum slot count: Lost Colony, Genesis, and Astraeos DLC all require at least 26 slots. The implementation is deliberately generic and can accommodate additional games and restriction types, including minimum RAM and minimum slot constraints, without structural changes to the underlying tables.

Cache behavior is documented clearly and has practical implications for anyone adjusting restrictions. Non-service-aware endpoints cache for 24 hours; service-aware endpoints for a full week, with the longer TTL explicitly motivated by patch-day load management. A 15-minute fingerprint TTL on both watches for changes in the restriction tables, meaning a database update propagates to the API within 15 minutes without a manual flush. An admin-area override handles cases where a customer's service was re-created after the restriction start date and would otherwise be incorrectly restricted.

The website speed performance initiative, led by Timo Huber, targets specific customer-facing flows where load time has the most visible impact: the start page, offer pages, and the checkout process. A Tech Stack overview update in May kept the component-to-team reference current. The stand-up from 15 May noted investigation and mitigation of an nginx CVE alongside routine development work; this appears to have been resolved without significant disruption.

The IO Teams & Stakeholders page, updated on 7 May by Patrik Müller, is the primary incident escalation reference for anyone who needs to route a problem quickly. It maps twelve distinct teams across three categories: Tech Teams, including APPS, B2B SRE, CI, CAD, DCS, NETOPS, IO, and Platform; Product Teams including GF, PG, and STS; and Service Units covering BI, DSB, Finance, HR, Partnerships, and Marketing. Each entry lists the team's responsibilities, on-call status, and the appropriate contact path.

On-call coverage varies significantly across the teams documented. APPS, B2B SRE, CI, NETOPS, Platform, PG, and STS all carry on-call support. DCS (Datacenter Services) and the IO team itself are listed as not on-call, with IO routing through the #team-infrastructure Slack channel for provisioning, infrastructure lifecycle, and patching tasks. For incidents involving personal data, the correct escalation is DSB (Data Protection Office) at dsb@nitrado.net; Finance and HR escalation paths are also documented for incidents with financial or personnel impact.

The IO Glossary, updated the same day by Mohamed Nasser, maintains the shared vocabulary that makes cross-team communication across a distributed infrastructure function tractable. Both documents reflect what a mature operations function does in a quiet period: not every week produces incident postmortems, and the absence of operational pages in the space is unremarkable in itself. Infrastructure running cleanly leaves less to write about, which is generally the desired outcome.