Release evidence · Updated 14 October 2026
Progress you can check.
Phase Four is in progress. New runtime work is being tested, while the published release remains v0.4.0-alpha.1.
Development evidence is not release acceptance. Do not install a moving feature branch on a customer node. All-phase security assessment, review, release packaging and remaining pilot checks must be completed before the next release is announced.
| Capability | Current boundary |
|---|---|
| Phases 1–3 | Completed development-alpha milestones: Docker Minecraft hosting, everyday management, guided game workflows and node reservations. Real-player/load and production gates remain separate. |
| Installation, host repair and private-release updates | Released in the existing alpha. Historical pilot upgrade verified 30 September 2026; see the dated walkthrough. |
| Game installation repair and undo | Merged through PR #5 and deployed in the unpublished development candidate on 14 October. Awaiting a containing release. |
| Applications and deployment rollback | Development branch. Disposable Docker startup, repeat-request reconciliation, rollback and failed-candidate recovery passed for Python, Node.js and static sites. |
| Domains and HTTPS | Development test passed public DNS ownership, Let’s Encrypt issuance, trusted off-host HTTPS and edge restart continuity. Scheduled certificate renewal remains unverified. |
| Exclusive native Vanilla hosting | Development branch. Fresh Debian 13 and Ubuntu 24.04 VMs passed actual non-root agent commissioning, Vanilla startup, console, agent restart continuity and Linux reboot. Review fixes passed native SFTP and interrupted-restore reboot checks. Security and remaining operator acceptance remain open. |
Bots, services and static sites
The application workspace allocates CPU, memory and a node port against the same capacity budget as games. An owner or administrator selects a public GitHub repository and a full commit SHA, then deploys it with an operator-approved, digest-pinned runtime.
- Operator prepares the node and approved Python/Node/static runtime image, including dependencies and an appropriate egress policy.
- Administrator allocates the application to a customer. Environment values are stored encrypted and are not shown again.
- The node validates a bounded source archive and starts an unprivileged container with read-only source and resource limits.
- HTTP applications pass a health-path check; bots must remain running. Bot process readiness alone does not prove successful third-party login.
- Failed candidates restore the previous process. Retained releases support explicit rollback; external databases and data are not rolled back.
Current limits: public GitHub snapshots only, dependencies supplied through approved images, brief deployment downtime, no arbitrary Dockerfiles or private Git credentials. Inactive releases and owned domain routes can be removed explicitly. Browser deployment from a real public Git commit, Start/Stop, keyboard access and 390px layout passed. All seven CI jobs passed at deployed runtime 393b81d, including Docker recovery, the Caddy local-CA fixture and the complete browser flow. Terminal operation receipts now move to a private SQLite index before the hot journal is trimmed. Tests passed 1,100 operations and replay checks, interrupted compaction, missing archives and real quota exhaustion. Operators can inspect usage and export receipts; the live index must remain with its journal and needs sufficient disk capacity.

Open the mobile Start/Stop evidence.
Custom domains
A claimed hostname needs a Nodara TXT ownership record and A/AAAA records pointing to the node’s configured public edge IP. A separate, operator-commissioned Caddy instance handles application HTTPS. It must not overwrite the panel proxy or another application’s route. A configured route remains awaiting_https until a trusted certificate and successful public response are actually verified.
Two hosting modes, with an explicit boundary
Shared nodes keep Docker isolation. Different customers can use separate containers with resource limits. An ordinary node reservation still uses Docker.
Native development targets an empty node assigned exclusively to one customer. The backend uses persistent systemd services, separate Linux identities, cgroup limits and a local console socket. It does not require Docker to execute the game workload. It never converts a populated shared node in place.
The first native scope is pinned Vanilla with lifecycle, console, metrics, files/SFTP, local backups and world management. Docker-specific runtime swaps, curated add-ons, selective game repair and remote-backup adapters are not yet native capabilities. Debian and Ubuntu commissioning/reboot checks passed at revision dcf3a64, including native SFTP creation/read/removal and a second reboot during interrupted restore. Three independent review findings were fixed and covered by regressions. Final Phase Four CI also passed application rollback-health and proxy-readiness corrections. There is no measured claim of reduced CPU/RAM use or better performance.
Recoverable native code upgrades
Protocol-1 commissioned nodes now have an offline helper upgrade and rollback command. Stop games through the panel first. The updater preserves one prior helper, gates agent operations during publication and verifies health before reopening access. Configuration, credentials and game data remain outside the code transaction. Dependency, Java/Python and unit-contract changes need a separate migration. Ten isolated Linux upgrade tests passed, including interrupted cleanup and refusal preserving the prior rollback copy. Both Debian and Ubuntu passed actual publication, authenticated health, explicit rollback, unhealthy-candidate recovery, process loss during publication, reboot recovery and a subsequent upgrade/reboot with real Vanilla startup at 5a5a143. World and protected configuration hashes remained unchanged. This is verified development evidence; release and pilot gates remain open.
All-phase security acceptance
The requested upstream Strix assessment covers authentication/MFA, tenant permissions, agent access, files/SFTP, backups, schedules/databases, game recovery, maintenance helpers and both new hosting backends. It is scoped to disposable Nodara environments, not the shared pilot’s unrelated applications.
Strix was installed and an authenticated scan was initiated, but the provider blocked the scan request before a completed assessment was produced. After the account holder reported access approval, a fresh candidate scan was attempted on 13 October 2026; the provider rejected that request with the same cybersecurity guardrail. Usable provider access remains unresolved. No clean scan, security certification or vulnerability-free result is claimed. Reproduced findings must be fixed and retested alongside functional regression checks.
Development pilot · 14 October 2026
The operator authorized bounded development tests on the existing shared server. The protected updater installed unpublished candidate v0.5.0-alpha.1 at 393b81d, after independent helper commissioning and a consistent rollback backup. Source delivery used a reviewed local bundle; this does not establish published-release download acceptance. The existing panel remains available, and unrelated workloads were preserved.
A temporary Cloudflare DNS-only hostname passed TXT ownership and direct-edge address verification. A dedicated Caddy listener on the public IPv4 address obtained a trusted Let’s Encrypt certificate without replacing the existing panel or private-access listeners. All 100 off-host HTTP requests at concurrency four succeeded. Certificate and route state survived an edge restart; conflicting ownership was refused. The application, edge and two test DNS records were removed afterward.
Development fixtures passed browser-driven MariaDB creation, password rotation and deletion; MinIO export, restore and deletion; local file backups; and real SFTP transfers, shell denial and revocation. A local SMTP fixture passed authenticated STARTTLS with certificate validation. Synthetic backup data restored on a separate Docker host with matching hashes and ownership. These checks do not establish external mail delivery, production storage/database configuration, real-player load or whole-node disaster recovery. Host security acceptance remains open.
Before calling Phase Four complete
- The original runtime work passed all CI at
dcf3a64. The continuation passed all seven CI jobs at5a5a143: regression, applications, both native upgrade/reboot VMs and the existing Linux/Debian/Ubuntu repair checks. The two continuation review findings were fixed and verified. Complete the operator and release gates below. - Complete the all-phase Strix assessment, triage and retest; explicitly list untested material boundaries.
- Verify scheduled public certificate renewal. Initial ownership, issuance, off-host HTTPS and restart continuity passed on the authorized temporary development edge.
- Complete release review and published-artifact delivery acceptance. Compatible local packaging, helper commissioning and the authorized development upgrade passed; no production release was published.
- Complete real-player gameplay, representative load and whole-node off-host disaster recovery. Configure the intended external SMTP, storage and database providers; disposable integration fixtures and synthetic off-host restoration passed.
- Publish documentation and real screenshots matching the tested release, then check the deployed website.
Checkout/billing and storefront work remain separate. Phase completion will be updated from this evidence, not from a calendar date.
Install the reviewed alpha · Inspect the historical pilot · Compare Nodara with stock Pterodactyl