Tested scope: The downloadable preflight passed in an Ubuntu 24.04.4 LTS ARM64 container on September 8. Installer download and shell syntax passed and the entry point reported
v260904. The full product, console login, development host and restore procedure were not installed or accepted in that test.
1. Allocate an isolated evaluation host
The project README lists a console minimum of 2 cores, 4 GB RAM and 40 GB storage; a development host is separately listed at 8 cores, 16 GB RAM and 100 GB. These are published starting figures, not a concurrency guarantee. The preflight container is not a replacement for both roles.
Use a disposable Ubuntu VM, retain console access and take a VM snapshot. Note its architecture, free storage and intended network routes. Install basic OS tools if absent, then run the read-only preflight:
sudo apt-get update
sudo apt-get install -y curl ca-certificates procps python3
curl -fL https://monkeycode.cc/examples/ubuntu-preflight.sh -o ubuntu-preflight.sh
less ubuntu-preflight.sh
bash ubuntu-preflight.shExpected output includes OS, architecture, CPU, memory, storage, “Installer syntax: passed” and a version label. See the actual preflight output. It does not create a MonkeyCode service.
2. Download and verify before deciding to install
Open the English package preparation flow on the evaluation host. It downloads the official entry as text, obtains a fresh signed package URL, and requires the reviewed package SHA-256, archive layout, manifest version/architecture and compose SHA-256 before extracting. It never executes either installer. On 2026-10-20 both architecture packages were downloaded and checked; product installation and runtime acceptance were not performed.
The entry bytes change when signed URLs change, so an old whole-entry hash cannot identify the package. The shared flow keeps package integrity mandatory and stops on an unknown release or any mismatch. Review the extracted install.sh, package.env, docker-compose.yml, .env.example, manifest.json and bundled installer, including their external downloads. Only after your own review, change into the printed directory on a disposable Linux host with a snapshot and separately decide to run sudo ./install.sh.
For exact v261009 reproduction, use your own retained package through the retained-package option; the same checks apply. This site does not distribute historical packages or promise that older official downloads stay available. Keep the original package and verification.json privately. These are independent measurements, not a vendor signature; image tags and runtime downloads remain mutable. A download failure can be retried from a new directory to refresh the URL. A version, hash, manifest or archive failure needs review before retrying. This package-only check does not extend the historical Ubuntu container test above into a completed product installation.
Read the first-hand package preparation record for compressed bytes, package and Compose hashes, manifest fields and read-only recalculation. Its actual host was macOS arm64; the amd64 check only overrode architecture detection. It does not establish an Ubuntu product installation.
3. Follow the generated configuration
Use the addresses and service instructions emitted by your actual installation. This guide does not invent a console port, default password or systemd service name. Configure the console and development host, then connect a test repository and an available model route. Check that the environment can fetch dependencies and run its test command.
4. Accept a complete task before adding team code
Run the first task from clone through diff review. Reconnect after restarting the task environment and verify the files and recorded outcome. Save the installed version, runtime/image versions, configuration locations and backup/restore commands actually provided by that release.
Recovery
A root/OS/architecture rejection means the installer’s prerequisite is unmet. A package download failure may require a fresh entry-point script and a network check. If installation is partial, inspect its output and restore the disposable VM snapshot before trying again. Do not assume repeated execution is idempotent. Validate backup restoration in another isolated host before calling the deployment production-ready.