MILO can run directly from source with Node.js/npm or be deployed using its Docker image. For release downloads, see GitHub Releases; each release provides its source ZIP and release notes. The published container image is ghcr.io/kenwetech/milo.

Run From Source

1. Download and extract the laatest ⁠MILO-vX.X.X.zip⁠ archive from GitHub Releases.

2. Install the project dependencies from the project directory:

   npm install
   

3. Set the environment variables you need (see Configuration).

4. Start the server:

   npm start
   

The default port is 8088, and the server listens on 0.0.0.0. On a network where mDNS works, you may also be able to access MILO at http://milo.local:8088.

Docker Compose

The container needs persistent storage for its database, a mounted master music collection, and a persistent location for the administrator library and the base directory used by relative library paths. A starting compose.yaml is shown below:

services:
  milo:
    image: ghcr.io/kenwetech/milo:latest
    container_name: milo
    restart: unless-stopped
    ports:
      - "8088:8088"
    env_file:
      - .env
    environment:
      PORT: 8088
      MASTER_POOL_DIR: /music
      LIBRARY_PATH: /app/MILO_Libraries
    volumes:
      # MILO database, sync history, and organizer history
      - ./data:/app/data
      # Library root used by the initial admin and relative user-library paths
      - ./MILO_Libraries:/app/MILO_Libraries
      # Your existing master music collection (write access is needed by the Organizer)
      - /path/to/your/music:/music
      # Persist certificates when using MILO's built-in HTTPS
      - ./ssl:/app/ssl

Replace /path/to/your/music with the host directory containing the master music collection. Keep ./data, ./MILO_Libraries, and (when using built-in HTTPS) ./ssl in persistent host storage so application history, user-library links, and certificates survive container replacement or upgrades. Ensure the container user has enough permission to read the master music and create library links.

How LIBRARY_PATH works: In this example, the initial administrator's library path is /app/MILO_Libraries. LIBRARY_PATH also serves as the base for relative library paths for other accounts. For example, entering alice as a user's relative library path resolves to /app/MILO_Libraries/alice. An absolute library path is used as given, so it must also exist and be accessible inside the container. The library root must be a persistent mount; otherwise a container replacement can discard its directory structure.

Set a strong FLASK_SECRET_KEY in the .env file next to your Compose file. For example:

FLASK_SECRET_KEY=replace-with-a-long-random-secret
SPOTIPY_CLIENT_ID=
SPOTIPY_CLIENT_SECRET=
APPLE_DEVELOPER_TOKEN=
DRIVEPOOL_DRIVES=

You do not need to set DB_PATH for the Compose example above; it defaults to the app's data/milo.db path, which is persisted by ./data:/app/data. MILO also stores sync_history.db beside the configured main database, so keeping the database directory persistent preserves that history too.

When accessing MILO from the host, open http://localhost:8088. On another device, use the server's LAN address and port. http://milo.local:8088 may work if mDNS announcements are available across your network and Docker setup.

DrivePool and Docker

The DrivePool physical-path lookup uses configured Windows drive letters and PoolPart.* folders. A typical Linux-based container cannot directly use host Windows drive letters such as D: or E:. Configure DRIVEPOOL_DRIVES only in a deployment where those paths are actually visible in the MILO process; do not copy Windows drive letters into a Linux container and expect the lookup to work. Hard links still need compatible physical storage and permissions.