
      <p>Managing access differs between editions. We normalized the UX while respecting file formats and identity systems.</p>

      <h2>Java</h2>
      <ul>
        <li><strong>Identity:</strong> Mojang UUID (online-mode=true)</li>
        <li><strong>Files:</strong> <code>ops.json</code>, <code>whitelist.json</code>, <code>banned-players.json</code></li>
        <li><strong>Lookup:</strong> Mojang API by username → UUID</li>
      </ul>

      <h2>Bedrock</h2>
      <ul>
        <li><strong>Identity:</strong> Xbox Live XUID</li>
        <li><strong>Files:</strong> <code>whitelist.json</code>, <code>permissions.json</code></li>
        <li><strong>Ops:</strong> via <code>permissions.json</code> with role <code>operator</code></li>
      </ul>

      <h2>How we apply changes</h2>
      <ul>
        <li>Write JSON into the container’s mounted <code>/data</code></li>
        <li>Reload: quick restart or in-game command (where supported)</li>
        <li>Skins & avatars: optional lookup for a nicer UI</li>
      </ul>
    

Player Management: Java vs Bedrock


      <p>We use Stripe Checkout to start a subscription, then rely on webhooks to activate services. Items can be added later with or without proration depending on the plan.</p>

      <h2>Events we handle</h2>
      <ul>
        <li><code>checkout.session.completed</code> → store customer, link to account</li>
        <li><code>customer.subscription.created/updated</code> → sync status, <code>current_period_end</code></li>
        <li><code>invoice.paid</code> → extend access if needed</li>
        <li><code>customer.subscription.deleted</code> → schedule shutdown/cleanup</li>
      </ul>

      <h2>Adding more servers</h2>
      <ul>
        <li>If an item exists for a product, bump <code>quantity</code></li>
        <li>Otherwise create a new <code>subscription_item</code> (with metadata for mapping)</li>
        <li>We typically bill on the next invoice, then provision immediately</li>
      </ul>

      <h2>Trials & grace</h2>
      <ul>
        <li>Trials via Checkout; we track <code>trial_end</code> and nudge with email</li>
        <li>Grace states when payment fails; periodic reminders; eventual stop</li>
      </ul>
    

Stripe Subscriptions That Don’t Hurt


      <p>We tested Traefik for TCP/UDP routing to map <code>subdomain → container</code>. While TCP (Java) was fine, UDP (Bedrock) proved fragile and added operational complexity.</p>

      <h2>What we tried</h2>
      <ul>
        <li>Traefik entrypoints for <code>:25565/tcp</code> and <code>:19132/udp</code></li>
        <li>Docker labels for dynamic routers/services per container</li>
        <li>OVH firewall rules to allow UDP 19132+</li>
      </ul>

      <h2>What we shipped</h2>
      <ul>
        <li>Per-server A record → node IP</li>
        <li>Per-server SRV record → service <code>_minecraft._tcp</code> (Java) or <code>_minecraft._udp</code> (Bedrock) with the correct host port</li>
      </ul>

      <h2>Why SRV won</h2>
      <ul>
        <li>Simpler mental model: domain points directly to the node + port</li>
        <li>Less moving parts; easier debugging; works great with multiple nodes</li>
      </ul>

      <h2>Gotchas</h2>
      <ul>
        <li>Cloudflare: SRV targets must be <em>hostname</em> (we create matching A)</li>
        <li>Do not proxy Minecraft over Cloudflare; keep records unproxied</li>
      </ul>
    

DNS & Routing: From Traefik UDP to Cloudflare SRV


      <p>Provisioning is a single API call away. The Fastify route validates input, selects a port, and asks Dockerode to create + start the container.</p>

      <h2>What we set at create time</h2>
      <ul>
        <li><strong>Image:</strong> Java or Bedrock, chosen by product</li>
        <li><strong>Volumes:</strong> bind host <code>/mc-servers/{name}</code> to container <code>/data</code></li>
        <li><strong>Ports:</strong> Java <code>25565/tcp</code>, Bedrock <code>19132/udp</code> with host port mapping</li>
        <li><strong>Env:</strong> <code>EULA=TRUE</code>, <code>SERVER_NAME</code>, <code>MAX_PLAYERS</code>, etc.</li>
        <li><strong>Restart:</strong> <code>unless-stopped</code> for resilience</li>
      </ul>

      <h2>Graceful stop & logs</h2>
      <ul>
        <li>Stop: <code>container.stop()</code> after sending <code>say</code>/save via exec if needed</li>
        <li>Logs (Java): <code>exec</code> <code>cat /data/logs/latest.log</code> and stream back</li>
      </ul>

      <h2>Health & stats</h2>
      <ul>
        <li>Stats endpoint aggregates <code>docker.stats</code> (CPU %, RSS) + host load average</li>
        <li>Used by scheduler to place new servers on the best node</li>
      </ul>
    

On-Demand Provisioning with Dockerode + Fastify


      <p>We tuned resource allocation to keep TPS stable under typical loads. Our default profile balances memory and GC without being too opinionated.</p>

      <h2>Container limits</h2>
      <ul>
        <li><strong>Memory:</strong> container <code>Memory</code> cap maps to server size (Small/Medium/Large)</li>
        <li><strong>CPU:</strong> <code>CpuShares</code> to prevent noisy neighbors, with headroom for spikes</li>
      </ul>

      <h2>JVM & server flags</h2>
      <ul>
        <li>Use the image’s sane defaults (Java 21 variants) and keep GC simple</li>
        <li>Prefer vertical scaling (RAM) before horizontal split for tiny communities</li>
      </ul>

      <h2>When to scale</h2>
      <ul>
        <li><strong>Scale up:</strong> sustained memory >80% or frequent GC pauses</li>
        <li><strong>Scale out:</strong> heavy plugins/modpacks, many concurrent redstone farms</li>
      </ul>
    

Optimizing Java Servers for Smooth Gameplay


      <p>We’ve been busy: Docker orchestration with Dockerode, experiments with Traefik for TCP/UDP, Cloudflare SRV records, and a clean Fastify API. This post covers the decisions we made and why.</p>

      <h2>Key milestones</h2>
      <ul>
        <li>Stripe subscriptions + webhooks (checkout, trial, proration choices)</li>
        <li>Fastify + Dockerode container manager with per-server volumes</li>
        <li>Traefik vs direct SRV—what we shipped and why</li>
      </ul>

      <h2>The stack</h2>
      <ul>
        <li><strong>API:</strong> Fastify (TypeScript), productized endpoints for start/stop/stats/logs</li>
        <li><strong>Containers:</strong> <code>itzg/minecraft-server</code> (Java), <code>itzg/minecraft-bedrock-server</code> (Bedrock)</li>
        <li><strong>Provisioning:</strong> Dockerode createContainer + PortBindings + bind-mounted <code>/data</code></li>
        <li><strong>DNS:</strong> Cloudflare API for A + SRV per server (no wildcard proxies)</li>
        <li><strong>Payments:</strong> Stripe Checkout + webhooks (invoice.paid, subscription.updated)</li>
      </ul>

      <p>Next up: autoscaling policies, richer metrics, and more locations.</p>
    

GlitchNode Blog

Player Management: Java vs Bedrock

Stripe Subscriptions That Don’t Hurt

DNS & Routing: From Traefik UDP to Cloudflare SRV

On-Demand Provisioning with Dockerode + Fastify

Optimizing Java Servers for Smooth Gameplay

Launch Notes: Building Our Minecraft Hosting MVP