Skip to content
Tenmon logo
Restricted early accessPlatform status

You build the bots.We run the gateway.

Tenmon is a managed cloud platform for Discord gateway workloads. We operate the gateway nodes, place each shard against cluster health and capacity, and coordinate migrations — so your team can stay on the bot.

Request early access (opens in a new tab)See how it works

Access is limited while the platform is validated. Check system status for current availability.

  • Managed gateway fleet
  • Resource-aware placement
  • Coordinated migration

Illustrative gateway control panel showing shards distributed across three gateway nodes while one shard is moved to a node with more room.

gateway controlIllustrative

Gateway fleet

3 nodes · 12 shards

Reconciled
node-a
Healthy
0123
node-b
Receiving
4567
node-c
Draining
891011

Shard 7 migration

node-c → node-b

placement: reconciledtenmon.xyz

How it works

From your application to a placed shard

You bring the bot. Tenmon operates the gateway nodes, the scheduler, and the work between them.

Step 01

Connect your Discord application

Register the application and its bot credentials with Tenmon. Credentials are stored encrypted and used to run the application's gateway workload.

Step 02

Tenmon places the shards

The control plane weighs node health, CPU and memory pressure, current shard count, and remaining capacity before assigning a shard to a gateway node.

Step 03

Placement stays reconciled

Tenmon tracks each shard as scheduled or running. When placement should change, the control plane updates the assignment and coordinates the move to another node.

No gateway nodes to provision. No scheduler to maintain. No shards to move by hand.

Tenmon operated

Platform

Gateway operations, handled

Tenmon is the operator of the gateway fleet. These are the jobs the platform performs so your team does not have to.

Interface examples in this section are illustrative, not live cluster data.

Managed gateway fleet

Tenmon runs the gateway nodes and the Discord gateway sessions assigned to them. You do not provision machines, keep gateway processes alive, or rebalance capacity yourself.

node-a
Healthy4 shards
node-b
Receiving4 shards
node-c
Draining4 shards

Resource-aware placement

Before a shard is assigned, the scheduler looks at node health, CPU and memory pressure, current shard count, and remaining capacity. Nodes under pressure are passed over for nodes with room.

  • Node health
  • CPU and memory
  • Shard count
  • Capacity left

Coordinated migration

When a shard should move, the control plane updates its node assignment and scheduled state while the workload transitions. Placement is a platform action, not a manual shard shuffle.

Shard 07node-c → node-b

Shard and node visibility

Shards report as scheduled, running, or migrating, with the gateway node that holds them. You get a clear view of placement without reading cluster internals.

shard 07Migratingnode-b
shard 02Runningnode-a
shard 11Schedulednode-b

Pre-handle events in the dashboard

Write small, safe logic in an in-dashboard editor and run it against your events before they reach your infrastructure. Drop noisy events at the edge (for example presence or high-volume commands) so they never go over gRPC to your bot.

This feature is not implemented yet, but it's designed to give you tight control over what hits your app without changing your gateway client.

  • Block events before dispatch
  • Reduce gRPC egress
  • Run per-application rules
  • Keep logic close to placement
dashboard / pre-handle.jsExample
// Run before dispatching to your gateway app
export function preHandle(payload) {
  const { guildId, userId, intent } = payload;

  // Drop noisy presence-like events at the edge
  if (intent === "PRESENCE_UPDATE") {
    return { action: "drop" };
  }

  // Rate-limit heavy commands to protect infrastructure
  if (guildId === "123456789" && intent === "APPLICATION_COMMAND") {
    return { action: "drop", reason: "rate_limited" };
  }

  return { action: "allow" };
}

Architecture

Desired placement, continuously reconciled

A control plane observes the fleet, decides where shards should run, and reconciles the gateway nodes to match.

The operating model

You interact with the service, not the cluster.

Tenmon keeps desired placement and actual placement in sync. The gateway nodes, scheduler, and coordination store are ours to run.

Coordination state

Cluster state lives in a coordinated store, so scheduling decisions reflect the whole fleet.

Encrypted credentials

Bot tokens and application configuration are stored encrypted and used to run the gateway workload.

etcdPostgreSQLGateway nodesplatform components

  1. Observe

    01

    Health, load, capacity, and current shard placement are read from the fleet.

  2. Schedule

    02

    Eligible nodes are ranked by resource pressure, shard count, and remaining capacity.

  3. Reconcile

    03

    Desired placement is compared with what each node is actually running.

  4. Migrate

    04

    When placement changes, the control plane coordinates the move and updates shard state.

Working with Tenmon

What stays yours, what we run

You keep the application. Tenmon takes the gateway layer so your team can focus on the bot.

Yours

The application

  • Bot logic, commands, and interactions
  • Your application data and features
  • Your own service deployment

Build and ship the features your community uses.

Tenmon

The gateway fleet

  • Gateway sessions and shard workloads
  • Placement across gateway nodes
  • Node health, capacity, and migrations
  • Encrypted bot credentials

The cluster, scheduler, and migrations stay on our side.

Restricted early access

Keep the bot. Drop the cluster.

Tenmon is onboarding a small set of teams while the platform is validated. Request access, or check the status page for what is running today.

Request early access (opens in a new tab)System status

Access is limited while the platform is validated.