Administration

Sign in with an administrator account and open /admin. Roosty only shows the administration navigation to administrators, and the server independently protects every administrator route.

The responsive administration menu separates the interface into:

Each active category refreshes its own JSON data every 15 seconds while the page is visible. The Refresh button performs the same in-place fetch; neither refresh mechanism reloads the document. The interface reads durable state from PostgreSQL, so it represents work across all Roosty server and worker processes using the database.

The local and remote account tables show 25 accounts at a time with Previous and Next navigation. Select the Account, Email, Role, State, or Created column heading to sort it and select it again to reverse the direction. Email and Role apply only to local accounts. Search, sorting, and pagination are preserved in the page URL.

Public registration is not currently available. Create local user and administrator accounts from the administrator interface. Roosty generates a temporary password that must be passed to the account owner securely. The temporary password is not retained in the audit log.

For the first administrator, use the bootstrap command documented in Create the first account.

Use the account action in /admin/accounts to generate a new temporary password. Give it to the account owner through a secure channel and ask them to replace it at /auth/edit.

When the web interface is unavailable, run the password-reset command inside the deployed Roosty container:

Administrators can limit a local or cached-remote account without discarding its ActivityPub data. A limited account is suppressed from discovery and public timelines and participates in notification filtering. Removing the limit restores normal presentation. The interface confirms account actions before submitting them.

Suspending an account immediately hides its profile and posts, revokes its sessions and tokens, cancels scheduled posts, and severs follow relationships. Suspending a local account also queues an ActivityPub Delete for its accepted remote followers before relationship cleanup. Its content is purged after 30 days unless an administrator unsuspends it; the compatible admin API can request an immediate purge. Suspending a cached remote account immediately removes its cached posts and relationships. There is no federated "unsuspend" activity, so unsuspension is local policy.

An administrator cannot suspend their own account or the final active administrator.

Use /admin/federation to create, edit, and delete domain rules. Rules are durable PostgreSQL configuration, so changes apply across every server and worker without restarting Roosty.

The Mastodon-compatible severities are:

A rule covers its subdomains. More-specific and parent rules are combined conservatively, so the strongest severity and rejection flags win. The old ROOSTY_FEDERATION_BLOCKED_DOMAINS environment variable is no longer read; recreate those entries on this page when upgrading.

Use /admin/moderation to manage the ordered rules shown by Mastodon clients. Rules are stored in PostgreSQL and appear through GET /api/v1/instance/rules and both instance metadata versions. Retiring a rule removes it from new reports without erasing the text captured by historical reports.

The same page lists local and federated reports. Administrators can assign, resolve, or reopen a report; remove an attached local or cached-remote post; and limit or suspend the target account. Local post removal queues the normal signed ActivityPub Delete. A cached remote post is removed only from this instance because Roosty cannot sign on behalf of its remote author.

Forwarded reports against remote accounts use a signed ActivityPub Flag. Incoming Flags pass through signature and replay validation. Enabling Reject reports on a domain rule acknowledges but discards Flags from that domain.

All active administrators receive an admin.report notification for accepted reports. OAuth clients use write:reports, admin:read:reports, and admin:write:reports. Custom moderator roles, warnings, and reportable collections are not yet implemented.

See the compatibility matrix for current compatibility details.

The work queue summarizes durable queue health and provides sanitized job diagnostics. Use it to identify delayed or repeatedly failing federation, media, notification, and scheduled-status work.

Diagnostics omit raw job payloads and secrets. Successful jobs are retained for 24h by default, while permanently failed diagnostics are retained for 30d. Worker processes clean both categories in bounded batches; operators can change the periods with ROOSTY_SUCCESSFUL_JOB_RETENTION and ROOSTY_PERMANENTLY_FAILED_JOB_RETENTION. Administrator mutations are recorded in the audit log, including whether the action came from the web interface, API, or command line.

For deployment logs, container operations, upgrades, and configuration changes, follow the procedures in Installation.