Bedrock Server Manager 4.1.0b1

Highlights

• Unified server backups: portable .bsmbackup recovery points with selectable contents, optional encryption, reviewed restores, verification, recovery drills, and external copies.
• Application backups: separate offline .bsmappbackup archives for the manager's database, configuration, credentials, installed plugins, and plugin data/themes.
• Persistent scheduler: automate backups, verification, pruning, server lifecycle actions, updates, console commands, world operations, and plugin tasks.
• Account security: revocable sessions, named integration tokens, authenticator MFA, recovery codes, remembered devices, and WebAuthn passkeys.
• Scoped access: finer permissions, per-server assignments, restricted integration credentials, and effective-access previews.
• Expanded plugin platform: operation context, typed event subscriptions, scheduled tasks, scoped settings, private/shared files, capability declarations, and live process/output inspection.
• Refreshed web interface: redesigned backup tools, schema-driven scheduler/settings forms, account-security controls, categorized permission badges, and experimental multi-instance/API Explorer workspaces.
• Shared typed contracts: canonical models across backend APIs, HTTP routes, and bundled plugins, with frontend consumers updated for the new response shapes.
• Improved runtime visibility: live health and diagnostics updates, clearer process ownership/readiness, and recovery of surviving untracked Bedrock processes.

Unified server backup and recovery system

One coherent recovery point

Server backups now use a portable, versioned .bsmbackup archive rather than relying on separately dated world and configuration files. Manual, scheduled, pre-update, and pre-start captures share the same backup pipeline.

Choose the contents for each capture:

• Global defaults capture the world and ordinary configuration/settings components, excluding server-level pack directories.
• Full-directory captures require Minecraft to be stopped.
• The server's entire script config/ directory can be preserved, including plugin/script configuration, variables, secrets, and module permissions.
• Captures record a manifest, inventory, checksums, component selection, and relevant platform/version metadata.
• Fast, Balanced, and Small compression profiles let administrators choose between compression effort and archive size.
• Existing .mcworld and configuration backups remain available as legacy recovery files. World import/export remains a separate content workflow.

Optional encryption and recovery keys

• Server backup encryption is optional and disabled by default.
• Encrypted archives protect the manifest, filenames, settings, and payload using SecureTar authenticated streaming encryption.
• Administrators can generate encryption credentials, export an emergency kit, rotate the active key, and test a recovery key against an archive.
• Archives retain their original key requirement after rotation.
• A server archive can be recovered on a fresh installation using the archive and its recovery key, without requiring the original BSM database.
• Supplied recovery keys can be used for recovery without being persisted as host credentials.

Selective, reviewed restores

• Inspect archive metadata and select complete components before restoring.
• Review added, replaced, and removed files, compatibility warnings, and capacity estimates before applying changes.
• Restore plans are bound to the archive and destination state; relevant changes require a new review.
• Dry runs extract and validate selected contents in isolated staging without replacing live data.
• Selected directories are replaced as components, while unselected data remains untouched.
• Restoring BSM server preferences preserves the destination's identity and runtime bookkeeping.
• Full-directory restore checks the operating system, architecture, and installed Bedrock version and requires a stopped server.
• Prepare a selected-component archive for restoration as a new server with a new name and ports, autostart disabled, and a stopped destination ready for normal review and restore.

Recovery after interruption

• BSM creates a safety backup before replacing live server data.
• A persistent recovery journal preserves the previous selected data/settings until the restore commits.
• Interrupted restores are reconciled during startup before plugin loading and server autostart.
• Pending recovery blocks unsafe normal startup and can be retried explicitly.
• Restore results distinguish committed data changes from later restart or cleanup problems.
• Failed or uncertain recovery keeps its journal and recovery material available for repair.

Verification, readiness, and archive management

• Verify archives manually or through independent schedules.
• Full readback verification after creation is off by default; an Unverified archive does not mean capture failed. Restore still authenticates and validates its input.
• Recovery drills exercise staged recovery and record a passed/failed result without replacing live data or launching Minecraft.
• Backup health reports age, key availability, destination coverage, storage concerns, drill results, and pending recovery.
• Export redacted JSON recovery reports for verification, drill, capacity, and restore evidence.
• Add labels and notes, pin recovery points, inspect capture-stage timings, and delete eligible archives explicitly.
• Archive changes invalidate stale verification/drill evidence.

Retention and external destinations

• Retention supports a recent-backup count, optional daily/weekly/monthly buckets, and a per-server storage budget.
• Pins, safety protection, and the last usable recovery point protect archives from ordinary pruning. A recent-backup count of zero disables automatic local pruning.
• Copy archives to configured existing directories, including mounted NAS paths or separate disks.
• Copies are verified before publication and have independent outcomes and bounded retry handling.
• External cleanup uses a preview-and-confirm workflow and preserves protected and untracked files.
• Local pruning and external-copy cleanup remain separate policies.

Faster captures and more responsive recovery

• World saves resume after capture, before compression/encryption completes.
• Capture, hashing, archive creation, verification, and restore staging avoid redundant work where validated evidence can be reused.
• High-file-count capture and sequential archive reads have been optimized.
• Filesystem-heavy recovery work is moved off the event loop so read-only application activity can remain responsive.
• Improved stage/progress reporting, timing measurements, cancellation cleanup, disk-space checks, and archive-size/file-count limits make long operations easier to diagnose.
• Fixed Windows flush handling that could fail backups and cancel startup.

New persistent task scheduler

BSM now has a database-backed scheduler with named schedules, bounded run history, timezone-aware execution, manual controls, and plugin-defined tasks.

Built-in tasks

Scheduling and controls

• Configure daily time, weekdays, IANA timezone, missed-run catch-up, task options, and a deterministic stagger window.
• Set a global application timezone, defaulting to UTC, for new schedules.
• Regional timezones follow daylight-saving transitions rather than fixed PST/PDT offsets.
• Schedules and run history survive BSM restarts.
• New schedules default to paused unless explicitly enabled.
• Run now, Pause, Resume, and Retry now controls are available; manual runs do not consume the next calendar occurrence.
• Revision checks reject conflicting edits from stale clients.
• Listings distinguish the next calendar occurrence from a queued manual/retry attempt.

Reliability and concurrency

• Catch-up runs only the most recent eligible missed occurrence rather than replaying every missed day.
• Failures receive bounded retries with backoff and a retry deadline.
• Exclusive scheduled work yields to interactive server operations without spending a failure attempt.
• Jobs are serialized per server, with configurable concurrency across servers.
• Startup reconciles interrupted runs and completed backup artifacts.
• Scheduler heartbeat, queue, failures, and timezone-data availability appear in health/diagnostics.
• Plugin schedules retain their configuration and history while their handler is unavailable, and become available again when the plugin returns.

Account authentication and security

Revocable login sessions

• Login sessions are now tracked and individually revocable.
• Inspect login/session metadata and sign out one session, other sessions, or all sessions.
• Administrators can inspect and revoke another account's sessions.
• Logout revokes the current session and closes its live connections.
• Session refresh preserves the original absolute lifetime rather than extending a session indefinitely.
• Configurable idle and maximum lifetimes bound interactive logins.
• Password resets revoke existing logins; security/account-authority changes invalidate affected authentication state.
• Upgrading from 4.0.2 requires a fresh sign-in because older untracked JWTs are rejected.

Named integration tokens

Create dedicated credentials for scripts, integrations, monitoring, and other headless clients.

• Give tokens a name, explicit capabilities, optional server restrictions, and an expiry, including Never expire.
• View active/inactive metadata, revoke credentials, or rotate a token while preserving its permission/resource ceiling and original expiry.
• The secret is returned once; only its digest is stored.
• Tokens remain limited by their owner's current role, activation state, and server assignments.
• Revocation and access reductions apply to subsequent requests and WebSocket deliveries.
• Tokens cannot elevate themselves into unrestricted sessions or delegate protected account/credential management.
• Effective-access previews show requested, effective, and unavailable permissions before creation.

Authenticator MFA and remembered devices

• Enroll an authenticator app for TOTP authentication.
• Generate ten one-use recovery codes; replacing the set invalidates previous codes.
• Login requests the second factor after successful username/password verification.
• Sensitive operations require recent verification, with a separate step-up flow.
• Remember a verified device for 30 days to reduce repeated OTP prompts; the password remains required for password-based login.
• Inspect and revoke remembered devices independently of login sessions.
• Administrators can optionally require MFA for administrator accounts.
• Local reset-mfa recovery supports locked-out accounts and clears enrolled factors, passkeys, and remembered devices.

WebAuthn passkeys

• Register, list, rename, and revoke account passkeys.
• Use a passkey for passwordless login and recent-authentication verification.
• Passkey authentication requires user verification, such as a PIN or biometric check.
• Administrators can inspect account passkeys and clear them through account MFA recovery.
• Single-use challenges and versioned security checks prevent replay and stale concurrent factor proofs.

Passwords, invitations, and private credentials

• New/reset passwords require at least eight characters and reject common or highly repetitive values using a bundled offline list.
• New hashes use Argon2id; successful legacy bcrypt logins upgrade the hash.
• Authentication throttling is configurable by account and peer.
• Registration invitations use digest storage, bounded attempts, and atomic one-time redemption.
• Authentication responses are non-cacheable, and credential-bearing values are redacted from application logs.
• JWT signing, MFA encryption, and backup keys live in protected credentials/*.key files rather than ordinary settings.
• Swagger exposes readable permission requirements and uses separate bearer authorization for API exploration.

Granular permissions and per-server access

Existing user, moderator, and administrator roles remain, with an explicit capability catalog describing their access.

• Assign non-administrator accounts access to selected immutable server IDs with selected server permissions.
• Server assignments narrow the role's capabilities; they do not elevate the role.
• Integration tokens can further narrow their owner's access.
• Recreating a server or account with the same name does not transfer old identity-bound grants.
• Account access responses and previews expose effective permissions and policy revisions.
• Background tasks revalidate their initiating credential, capabilities, and server identity before queued work starts.
• WebSocket subscriptions and outgoing deliveries enforce current authorization.
• Plugin routes can declare their own namespaced HTTP permissions and explicit role grants.
• OpenAPI includes permission and contextual access metadata for clients and API tooling.

Representative HTTP scope groups include:

The final scope catalog separates lifecycle control from console commands, property reads from edits, installation from deletion, and backup management from retention pruning. World/addon operations have dedicated scopes distinct from shared content-library management. This allows narrower operator and integration grants.

Plugin-defined HTTP permissions can opt into server_scoped registration, so custom per-server endpoints participate in assignment validation, token previews, and effective-access checks. Destructive installation overwrites also check delete permission on the existing server and recent interactive verification where applicable. Health WebSocket access follows health:read.

Plugin-local settings continue to use plugin permissions. Plugin-defined global settings use global-settings permissions; plugin-defined server settings use that server's settings permissions.

Redesigned server process runtime and player tracking

Live output and readiness

• Owned Bedrock processes use asynchronous console pipes with one live-output consumer.
• Readiness, player presence, live output waits, and backup save responses consume the live output stream.
• A successful spawn remains STARTING until Bedrock reports readiness; early exit and startup timeout are visible failures.
• Slow database writes, plugins, and console viewers are kept outside the output consumer.
• Output pressure, persistence problems, ban-enforcement availability, and exit evidence are exposed through dedicated process status.
• Console writes have bounded deadlines and reject multiline/control-character input. An uncertain timeout does not prove that a command was never delivered.
• Stop/start cleanup is tied to the correct process generation to avoid stale work affecting a replacement process.

Event-driven players

• Online presence is updated from owned-process connection/disconnection output rather than the retired player polling interval.
• Player identities are retained for retry when database persistence is temporarily unavailable.
• Ban enforcement reacts to observed connections and committed ban changes.
• monitoring.player_interval_sec and its stored values have been removed.

Surviving process recovery

• Discover untracked Bedrock processes when PID information is missing or stale, validate their server-directory identity, and regenerate PID tracking.
• Throttle repeated system scans and expose settings for recovery enablement and scan interval.
• Report recovered process ownership, resource usage, and control limitations in status/diagnostics.
• Recovered survivors do not regain the lost console pipes, live readiness, or current player presence. They remain outside lifecycle monitoring and automatic restart until an explicit stop/start restores ownership.
• Offline-only maintenance still requires a fresh verified stopped decision, including when automatic recovery is disabled.

Plugin API and extension improvements

Event and operation context

Plugins can inspect immutable current-event and operation snapshots, including correlation IDs, parent/root relationships, timing, purpose, component scope, and domain outcome.

• self.api.events.current() identifies the current callback context.
• self.api.operations.current(), sequence(), and results(...) inspect work within the current operation chain.
• self.api.operations.scope(...) supports namespaced plugin operations.
• Global activity queries complement sequence-local results.
• Typed hooks and immutable observers are opt-in, alongside event discovery, subscription inspection, filtering, priority/order controls, temporary subscription scopes, and wildcard observation.
• Owner/generation binding cleans up listeners and invalidates stale capabilities on unload/reload.
• Existing 4.0 callback arguments and event decorators retain compatibility.

Operation results make it possible to reuse a completed qualifying backup within the same lifecycle sequence rather than guessing from recent timestamps.

New backup, scheduler, and process APIs

Live output waits support exact or substring matching, timeouts, and explicit generation/sequence cursors for bounded replay. They terminate on a match, timeout, exit, or plugin unload; stale generations and expired replay cursors fail explicitly.

Scheduler creation/deletion/control and selected internal management APIs are not exposed to plugins. The dedicated delete-backup API is internal, while permitted snapshot-management actions are available through the scoped management API.

Declarative extensions and scheduled tasks

• Declare scheduled handlers with @scheduled_task.
• Register existing APIs as tasks through scheduled_apis or runtime.register_api_task.
• Task options can use Pydantic schemas for validation and generated forms.
• Optional execution context supplies slot identity, attempt number, operation correlation, and a stable idempotency key.
• Declare diagnostic and WebSocket data providers with decorators.
• Declare HTTP permissions and web extensions on the plugin class.
• Legacy registration paths remain available where supported, with migration warnings.
• Scheduled plugin work is at-least-once across crashes; plugins performing external side effects should use the idempotency key.

Scoped settings and files

• Declare independent plugin-local, global, and server Pydantic settings models.
• Generated schemas provide typed controls, defaults, choices, validation, and existing-server selectors.
• Whole-namespace writes are atomic; field updates validate against current committed sibling settings.
• Settings reconciliation removes obsolete plugin fields/namespaces while preserving unrelated custom settings.
• runtime.read_plugin_file, write_plugin_file, and get_plugin_data_path support private and shared/public storage with JSON, text, and bytes.
• Scoped file helpers validate relative paths, reject traversal/symlinks, and use protected atomic writes.
• runtime.get_system_path resolves permitted host directories.

Plugin capability permissions

Plugins can declare permissions for sensitive in-process API operations. These are separate from HTTP account/token scopes.

The exported PluginScope enum provides typed names for the canonical plugin capability catalog. Sensitive reads as well as mutations now declare their required scope; bundled plugins have matching explicit declarations.

An omitted/None permissions declaration preserves legacy scope access. An explicit declaration, including an empty list, opts into enforcement. Some internal APIs remain unavailable to plugins regardless of declared scopes. These API boundaries do not sandbox Python code running with BSM's operating-system permissions.

Shared API models and client compatibility

• bedrock_server_manager.models is now the canonical package for shared request, response, and serializable data contracts.
• Backend APIs, HTTP routes, services, and plugin tooling share these models instead of maintaining divergent transport schemas.
• Bundled plugins and repository example plugins use direct Pydantic request models and typed response attributes at API call sites.
• Legacy api.models imports re-export centralized contracts, but integrations should adopt the canonical package for new code.
• HTTP routes expose canonical success/partial/error contracts, with typed backup-key list/rotation results and consistent schema generation.
• The frontend's generated contracts and response readers have been refreshed to match.

Two concrete HTTP changes matter to custom clients:

The unchanged operation names do not imply identical response bodies. Refresh generated clients and update custom parsing against the current OpenAPI document.

Bundled plugins and content management

• Backup on Start defaults to world-only capture and supports content/encryption overrides, coverage-aware reuse, configurable timeout, and optional mandatory completion.
• Update Before Start runs before Backup on Start, allowing an eligible completed pre-update backup to satisfy the sequence's pre-start requirement.
• Pre-start cancellation/timeout cleanup waits for owned workers before proceeding.
• Content upload/download/deletion is now owned by core routes rather than requiring the old uploader/download-page default plugins.
• Content operations use explicit read/manage access and validated filenames/archive contents.
• Addon subpack metadata is normalized for API responses, addressing response validation failures.
• Read-only addon inventory avoids exposing absolute host paths.
• The repository includes an administrator script-configuration editor plugin for permissions, variables, and secrets.

Diagnostics, live updates, and administration

• Global event/operation activity shows ancestry, outcomes, listener configuration, ordering/filter information, delivery statistics, and event-to-operation links.
• Correlation traces and support reports include the expanded activity metadata without exposing event payloads or task arguments.
• Authorized WebSocket clients can subscribe to health and diagnostics snapshots, including an immediate current-state replay.
• Process-manager, recovered-process, backup, scheduler, plugin, and background-task observations provide more actionable health findings.
• Refined health rules distinguish active work and historical failures from current unhealthy conditions.
• Transient diagnostic-history writes receive bounded retries.
• Logs include clearer operation durations, listener deadlines, backup stages, filesystem timings, cancellation, and background-task progress.
• Local logs tooling lists/views/follows application and server logs and identifies verified active logs.
• Cleanup tooling adds dry-run orphan inspection for plugin, server, and addon artifacts, stale PID cleanup, and protection for active logs/database files.
• Audit-log reads support bounded pagination.

Web interface — changes since frontend 1.3.0

Redesigned backup workflow

• A dedicated unified archive workflow replaces the old split world/configuration presentation.
• Compact summary cards and searchable recovery points show capture dates, health, readiness, verification, and recovery attention.
• Creation offers World only, Selected components, and Full server directory modes using choices from the backend schema.
• The inspector separates Restore options, Details, and Manage, with viewport-bounded dialogs and compact three-dot action menus.
• Review file/settings changes, choose components, run a dry run, and continue through a newly prepared server's restore review.
• Verify, pin/unpin, annotate, delete, copy, test recovery keys, run recovery drills, and download redacted recovery reports.
• Supported browsers can stream downloads to native save handles; transfer progress and cancellation are surfaced, with browser fallbacks.
• Long backup/recovery tasks show loading/progress feedback and preserve responsive interaction.
• Existing start/stop/restart requests can wait through long lifecycle hooks rather than using the ordinary short request timeout.
• Backup defaults, compression, retention, destinations, and recovery keys live in the reorganized Settings interface.
• External cleanup has an explicit preview and confirmation flow, including destination retention and free-space settings.

Scheduler page and schema-driven settings

• A new administrator Scheduler page supports creating/editing jobs, paused/enabled state, run history, and handler availability.
• Run now, Pause, Resume, and Retry controls use revisions to reject stale actions.
• Pending attempts, blocked reasons, and task-specific options make retry/deferral state visible.
• Plugin task options render from their schemas, alongside built-in tasks.
• Timezone selection includes regional choices and clear Pacific Time guidance; save errors identify rejected fields.
• Global Settings uses tabs and preserves unsaved drafts while switching between them.
• Plugin-defined settings appear in plugin, global, and server editors with scope-specific drafts and refresh behavior.
• Supported enum-array fields use labeled checkbox controls, including backup components.

Account security and permissions

• Account tools include Sessions, Integrations, My access, Activity, Password/MFA, remembered-device management, and passkeys.
• Progressive MFA sign-in prompts for the second factor only when needed.
• Sensitive actions open a recent-verification flow; remembered devices reduce repeated OTP prompts.
• Manage integration credentials with expiry choices, Never expire, a Full access preset within the owner's eligible permissions, active/inactive filtering, rotation/revocation, and one-time secret/copy feedback.
• Effective-access previews explain requested/unavailable scopes and selected server access before saving.
• Administrator server-assignment controls support scoped operators.
• Server cards and management controls check the specific action and server capability, including separate lifecycle, command, install, delete, and property permissions.
• Categorized, color-coded scope badges are shared across token, access, plugin, and API Explorer views.
• Recovery codes have explicit copy feedback and file-save controls, with fallback behavior.
• Audit history is paginated rather than loading the whole administrative history at once.
• Login offers username/password, integration-token, and passkey paths with a shared connection selector.
• The embedded default browser connection uses the backend's protected cookie-session flow; remote/saved connections and explicit integration-token login use bearer credentials. This describes the reviewed source, including its final connection-mode handling.

Diagnostics, monitoring, and timestamps

• Global activity views show events, operations, listeners, outcomes, trace links, and filtering by server, owner, sequence, correlation, or operation.
• Live health/diagnostic updates refresh authorized views over WebSockets.
• Frontend runtime observations can be recorded, filtered, inspected, exported, and optionally retained across reloads. Recording and persistence default to off.
• Diagnostic navigation is reflected in the URL, preserving the selected category on reload or direct links.
• Frontend history remains available when backend diagnostics cannot be reached.
• Date/time preferences support application timezone, browser timezone, or UTC and apply across backup, credential, and instance displays.
• Navigation titles/icons, copy controls, mobile settings panels, and action menus have been refined. Action menus no longer close on stale scroll notifications at an unchanged anchor.

Plugin and content interfaces

• Plugin cards show declared capability permissions, settings scopes, and runtime status with compact badges.
• Schema-based plugin editors support typed fields, nested values, choices, defaults, and scope-aware validation.
• Plugin-view styles are contained so opening a plugin does not restyle native controls.
• Content library screens support native upload, archive download, and deletion actions through core routes.
• Resource icons use authenticated fetching when required by backend permissions.

Experimental multi-instance workspace

Available behind ?hidden=true, with management accessed from the connection dropdown.

• Save named backend profiles, groups, colors, and optional tab-title preferences.
• Sign in to each backend independently and view a combined fleet with per-server actions, search, and connection/status filters.
• Open a full workspace in the same tab or another tab while keeping backend/account state separate.
• Test a connection, open the backend for troubleshooting, pause/resume profiles, and import/export credential-free profile metadata.
• Connection details show the backend, HTTP/socket state, last success, and refresh timing.
• Offline instances retain clearly marked last-known snapshots with actions disabled.
• Pending task history survives navigation/reload within the tab session. Lost mutation responses become Outcome unknown and are not automatically retried.
• Remote connections still require correct CORS/TLS configuration; browser certificate verification cannot be disabled by the frontend.

Experimental API Explorer and developer tools

Also behind hidden mode:

• Load the connected backend's OpenAPI document, upload JSON, or paste a contract.
• Search operations/models and follow local schema references.
• Build requests with schema-driven fields or JSON, inspect required/default values, and review access policy requirements.
• Separate Request, Response, and Schema views plus rendered/raw response displays expose status, headers, timing, copy/save controls, and array filtering/pagination.
• Multipart upload, binary download, and transfer progress are supported for relevant operations.
• Imported contracts do not redirect credentials to their declared server URLs; execution uses the selected connection and its backend authorization.
• The developer playground also gains rendered/raw views.

Frontend maintenance

• Adopted ESLint 10 and migrated React linting; fixed the resulting React findings and unstable rendered-list identities.
• Updated shared runtime/cache typings, generated API contracts, and dependency ranges.
• Added or extended browser/unit coverage for authentication, passkeys, backup recovery, schedules, multi-instance connections, and scoped access.
• Editable Python frontend installs can rebuild/copy assets through npm run build:editable without producing distribution packages.

Offline application backups

The local bedrock-server-manager backup group now supports .bsmappbackup creation, listing, inspection, recovery drills, and selective restore, with an interactive menu when run without a subcommand.

Creation and restore require BSM to be stopped. Game server directories, server backup archives, downloaded installers, and staged content are excluded; use server backups for game data. Application archives support encryption/recovery keys and isolated integrity/configuration drills. Check the reported encryption status: the current create implementation can produce plaintext when no active host backup key is available.

Offline server-archive extraction remains available through bedrock-server-manager backup extract, without requiring a running manager or the original database.

Backend and maintenance improvements

• Reorganized bootstrap configuration, database, runtime PID, log, plugin data, and private credential locations, with legacy-location handling.
• Existing default SQLite databases are preserved in place rather than moving potentially live database/WAL files; new installations use the nested database layout.
• Improved SQLite interrupted-operation cleanup, WAL setup, idempotent shutdown, startup sequencing, and bounded concurrent work.
• Strengthened asynchronous worker cancellation and plugin import cleanup.
• Consolidated validation/contracts and separated process inspection/log-wait models from lifecycle responses.
• Added regression coverage for recovery, permissions, authentication, scheduler behavior, Windows filesystem operations, and process lifecycle handling.
• Separated lint checks from build/test workflows and updated supported dependency ranges.
• Updated the frontend dependency from the 1.3 series to bsm-frontend >=1.4.0b1,<1.5.

Upgrade notes

1. Sign in again after upgrading. Old untracked login tokens are not accepted by the new session system.
2. Preserve the database and installation credentials together. Server archives do not contain manager accounts, grants, JWT/MFA keys, or global configuration.
3. Review backup defaults. Ordinary selected captures exclude server-level packs; Backup on Start defaults to world only. Full-directory capture requires a stopped server.
4. Verification is opt-in. Schedule verification/drills or enable readback after creation if needed.
5. Review separately hosted frontend origins. The default CORS allowlist is now empty; configure permitted origins explicitly.
6. Review plugin permissions and deprecated APIs. Legacy undeclared plugins preserve scope compatibility, while explicit declarations are enforced. Some management APIs are now internal-only.
7. Use regional timezones. Prefer America/Los_Angeles rather than PST/PDT for local calendar scheduling.
8. Expect limits on recovered processes. Discovery restores tracking, not lost console handles; stop/start is required for full live control.
9. Update integrations against the new access contract. Account/token scopes, server assignments, protected resources, and authorization checks now apply to HTTP, queued tasks, and sockets.
10. Use the final granular scope names. Earlier development declarations such as servers:control, servers:properties, servers:manage, singular plugin server:*/backup:* scopes, and maintenance:* pruning scopes have been replaced by the catalog above. Review explicitly scoped tokens, saved assignments, and plugin declarations; do not assume old names expand automatically. Scheduler task IDs such as backup:create remain singular and are a separate namespace.
11. Refresh custom HTTP response parsing and model imports. Adopt canonical models and check is_running and the unwrapped /api/info payload.
12. Treat multi-instance and API Explorer as experimental. They remain behind hidden mode and are not enabled by default.

What's Changed

🚀 Features

• feat: add scoped access, revocable sessions, and account MFA by @DMedina559 in #480
• Feat/dynamic scheduler functions by @DMedina559 in #483
• Feat/plugin permissions by @DMedina559 in #484
• Feat/app backups by @DMedina559 in #485
• Feat/improved process recovery by @DMedina559 in #488

⚡ Performance

• Perf/backup recovery by @DMedina559 in #478

⬆️ Dependencies

• dep: update pytest requirement from <9.2,>=8.4.0 to >=8.4.0,<9.3 by @dependabot[bot] in #479
• dep: update platformdirs requirement from <4.14,>=4.3.0 to >=4.3.0,<4.15 by @dependabot[bot] in #486
• dep: update flake8 requirement from <7.5,>=7.3.0 to >=7.3.0,<7.6 by @dependabot[bot] in #487

🧹 Chore

• chore: restructure runtime data and add cleanup/log tools by @DMedina559 in #481
• chore: promote content routes and add backup deletion by @DMedina559 in #482
• chore: add live health and diagnostics updates by @DMedina559 in #489
• Chore/centralize models by @DMedina559 in #490

Full Changelog: 4.0.2...4.1.0b1