Install ScenarioX Self-Hosted V1

This procedure installs the source-free customer package on one Linux x86_64 host. Run every command from the extracted package directory.

Before you begin

Prepare:

• Docker Engine with the Docker daemon running
• Docker Compose v2
• the release ZIP and its matching SHA256SUMS
• private registry access with permission to read the supplied images
• DNS names for the recruiter, candidate, and workspace runtime entry points
• a customer-managed HTTPS endpoint in front of the bundled HTTP edge
• an Anthropic API key

Self-Hosted V1 has no validated hardware sizing baseline. Test the intended assessment concurrency on representative customer infrastructure before production use.

1. Verify and extract the release

sha256sum -c SHA256SUMS
unzip scenariox-self-hosted-<image-tag>.zip -d scenariox-self-hosted
cd scenariox-self-hosted
cat VERSION
cat release/release-metadata.json

Stop if checksum verification fails or the release metadata does not match the release supplied by ScenarioX.

2. Create configuration and keys

cp .env.example .env
mkdir -p secrets
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 \
  -out secrets/scenariox-jwt-private.pem
openssl rsa -in secrets/scenariox-jwt-private.pem -pubout \
  -out secrets/scenariox-jwt-public.pem
chmod 600 secrets/scenariox-jwt-private.pem secrets/scenariox-jwt-public.pem

Replace every <...> placeholder in .env. Keep .env and secrets/ outside source control. See Configuration for each required value.

3. Authenticate to the image registry

Use a token with package read access. Do not place the token in .env.

export GHCR_USER=<github-user>
export GHCR_TOKEN=<token-with-read-packages>
printf '%s' "$GHCR_TOKEN" | docker login ghcr.io \
  --username "$GHCR_USER" --password-stdin
unset GHCR_TOKEN

If the registry organization enforces SSO, authorize the token before continuing.

4. Validate before startup

./scenariox config-check
./scenariox preflight

config-check verifies required values and key files without printing secrets. preflight also checks the Linux x86_64 host, Docker, Compose v2, and resolved customer Compose configuration.

5. Pull and start

./scenariox pull
./scenariox start
./scenariox health

Do not continue to administrator bootstrap until health reports successful database initialization and all readiness-backed services as healthy. A process-only warning means the container is running but no application readiness probe exists for that service.

6. Create the first administrator

./scenariox bootstrap-admin \
  --organization-name "Example Engineering" \
  --organization-slug "example-engineering" \
  --admin-email "admin@example.com" \
  --admin-full-name "Platform Administrator"

The command prompts twice for a password. Passwords require at least 10 characters with uppercase, lowercase, number, and symbol characters. The organization slug accepts lowercase letters, numbers, and hyphens.

Bootstrap is one-time only. A second attempt exits without changing records.

7. Sign in for the first time

Open the customer HTTPS URL for the recruiter application. You see a sign-in form with three fields.

After a successful sign-in the recruiter dashboard loads and the account menu in the top-right corner shows the organization name and your role (ORG_ADMIN). Access tokens expire after 15 minutes; you will be returned to the sign-in form automatically.

If sign-in fails:

Bootstrap is one-time only. Running ./scenariox bootstrap-admin again exits without changing any records. Contact the ScenarioX support channel if you need to reset the initial organization or administrator.

Use Troubleshooting for startup, readiness, or persistent sign-in failures.