Runtime and versions¶

By default a blueprint runs in the browser/WASM runtime: it boots a fresh, in-memory Moodle and applies the blueprint at startup, with nothing stored on disk. The same blueprint.json can also run in the sibling Docker runtime, alpine-moodle, which runs a real PHP + Nginx Moodle server in a container.

This page shows how to pick the Moodle and PHP version, and how to write a blueprint that stays portable across both runtimes.

Pick a Moodle and PHP version¶

There are two ways to select versions. URL parameters win for a quick one-off; preferredVersions makes the choice travel with the blueprint.

https://moodle-playground.com/?moodle=4.5&php=8.3

{
  "preferredVersions": { "php": "8.3", "moodle": "5.0" },
  "steps": []
}

Supported versions:

Browser runtime vs Docker runtime¶

The two runtimes are complementary. Pick one per task:

Write portable blueprints¶

To keep a blueprint working in both runtimes:

• Prefer explicit, ordered steps over runtime-specific shortcuts.
• Use stable identifiers so steps can reference each other: course shortname, category name, user username.
• Avoid steps that run arbitrary code or touch the filesystem (runPhpCode, runPhpScript, writeFile, unzip, …) — they are disabled by default in Docker.
• Keep remote resources small, or bundle them with the blueprint, for reproducibility.
• Treat landingPage as a hint; a Docker runtime may not navigate automatically.
• Treat preferredVersions as advisory (see the note above).

Step compatibility¶

The browser runtime supports every step in the reference. The alpine-moodle column below reflects its current, experimental implementation — always confirm against its blueprint documentation.

Steps not listed (batch variants, setConfigFile(s), installLanguagePack, role/scale/cohort steps, filesystem helpers, request, …) work in Moodle Playground; in alpine-moodle they are either planned or disabled and fail clearly rather than being silently ignored.

Example: a portable blueprint¶

This blueprint avoids browser-only and unsafe steps, so it runs in both runtimes. A copy lives at assets/blueprints/examples/docker-compatible.blueprint.json.

{
  "$schema": "../blueprint-schema.json",
  "preferredVersions": {
    "php": "8.3",
    "moodle": "5.0"
  },
  "landingPage": "/course/index.php",
  "steps": [
    {
      "step": "setConfig",
      "name": "debug",
      "value": 32767
    },
    {
      "step": "createCategory",
      "name": "Blueprint demo"
    },
    {
      "step": "createCourse",
      "fullname": "Blueprint demo course",
      "shortname": "BLUEPRINT101",
      "category": "Blueprint demo"
    },
    {
      "step": "createUser",
      "username": "student1",
      "password": "ChangeMe123!",
      "email": "student1@example.com",
      "firstname": "Student",
      "lastname": "One"
    },
    {
      "step": "enrolUser",
      "username": "student1",
      "course": "BLUEPRINT101",
      "role": "student"
    }
  ]
}

Open it in the hosted app:

https://moodle-playground.com/?blueprint-url=/assets/blueprints/examples/docker-compatible.blueprint.json

Run the same blueprint in Docker¶

Mount the blueprint and point MOODLE_BLUEPRINT at it:

services:
  moodle:
    image: erseco/alpine-moodle:latest
    ports:
      - "8080:8080"
    environment:
      MOODLE_DATABASE_TYPE: sqlite3
      MOODLE_USERNAME: admin
      MOODLE_PASSWORD: ChangeMe123!
      MOODLE_EMAIL: admin@example.com
      MOODLE_SITENAME: "Blueprint Demo"
      MOODLE_BLUEPRINT: /blueprints/demo.blueprint.json
    volumes:
      - moodledata:/var/www/moodledata
      - ./demo.blueprint.json:/blueprints/demo.blueprint.json:ro

volumes:
  moodledata: