# Operator limits and capacity

In SDK 1.11, Admin → Limits and capacity is the central policy editor. Search by
feature or setting key. Each group saves only changed fields, validates related
budgets together, and records previous/new values in the administrator audit log.
Admin authentication, CSRF and any configured MFA remain required.

Values are stored in the database. Restarting, redeploying, replacing a server or
adding a process does not reset an explicitly saved value. Move or restore that
same database when moving infrastructure; retain the normal persistent volumes,
encryption keys and database configuration. A new empty database has defaults.

There are no fixed commercial/product ceilings on these operating budgets. The
editor accepts finite integers up to the JSON safe numeric representation limit
(2^53−1); MiB fields account for conversion to bytes. Android bridge requests
and HTTP response buffers use Java byte arrays, so those two fields expose their
2^31−1 byte representation boundary in the editor. This is a representation
boundary, not an estimate that a server can deliver such a setting. Zero is
supported for retention/cache settings and explicitly labelled automatic sizing.
Relationships still matter: a queue byte budget must accommodate its admitted
request or batch, and a database pool minimum cannot exceed its maximum.

## Propagation and scope

Control and runtime processes coalesce database policy reads, with a one-second
cache. Native operations resolve fresh policy in their guarded transaction.
The operations worker refreshes policy before its bounded job passes. Multiplayer
loads policy in its existing authorization maintenance cycle and sends changed
public limits to connected SDKs. Existing browser players receive resource policy
through their existing heartbeat, and on session/focus checks; new launches get
it immediately. This adds no independent per-player configuration polling loop.
Android retains the last policy for offline play, adopts fresh native capabilities
and refreshes on session/focus checks with the configured SDK policy cache period.
An offline device receives current policy when it next connects and checks in.

Admission and worker/pool sizes are per process. App/account/room quotas keep the
scope named by their fields. Explicit subscription-plan overrides still apply to
the corresponding account quotas; Admin → Plans shows those values, and null
means inherit the platform setting. Raising a platform default does not silently
erase a deliberately configured plan override.

Raising a budget permits more work. Lowering admission does not cancel queued or
running durable operations. Admission quotas do not erase existing records or
active saves. Retention settings keep their cleanup behavior, including pruning
old history when retention is reduced. New writes/admission can return a quota/busy response until
usage fits or the administrator raises it again. Multiplayer remains ephemeral:
slow recipients can be disconnected when their live output budget is exhausted.
There is no automatic waiting list for full multiplayer rooms.

PostgreSQL save workers at zero retain automatic sizing from database topology;
a positive value selects that count directly. Creator per-account pending jobs
at zero use half the process pending budget; a positive value selects that count.
Database maintenance-thread and pool connection-startup settings are labelled
restart required. Services first need working database configuration to read
saved policy. They
retire their bootstrap pool when saved startup options differ, then create pools
with those saved options. Realtime adopts shared capacity settings from its
existing maintenance snapshot as well as its room settings.
Container/service replica counts, OS file descriptors, CPU/RAM, PostgreSQL max_connections, reverse
proxy upload/timeouts and shared Redis configuration are infrastructure settings;
the Admin editor does not provision or resize the underlying servers. Existing
multi-control-worker PostgreSQL/Redis requirements still apply. Run one room
broker worker: room hints are ephemeral in that broker; durable native session
state remains shared SQL state and can be reopened after broker restart.

## Covered settings

The catalog covers native module switches; records, indexes, queries, actions,
groups, invitations, notifications and scheduled jobs; authoritative sessions,
rule configuration and competitions; multiplayer admission, fanout, history,
output and input queues; database/creator/runtime/native workers and admission;
save queues, bytes, batches and deadlines; SDK JSON, progress, recovery, downloads,
watchers and browser bridge budgets; and existing account/upload/storage quotas.

Closed message fields, opaque identity/invitation formats, versioned schemas and
the browser Bluetooth protocol retain their format validation. These are protocol
contracts, not concealed throughput settings. A larger operational limit does not
change an app's own declared schema, save format, competition rules or chosen room
capacity. Apps should read Hackemist.capabilities(), honor returned limits and
surface busy/conflict/quota errors while retaining pending input. Native writes
must retry the same operation ID after an uncertain response.

Use Admin → Multiplayer and Operations to observe actual utilization and errors.
Increase budgets alongside measured CPU, memory, database and proxy capacity;
no configured number alone guarantees a concurrency level across every game.