Production builds

mochi-framework build writes a self-contained build to .mochi/ (see the CLI reference). This page covers what that build gives you once it is deployed: it relocates cleanly from where you built it to where you run it, and its image cache can survive container restarts. For where to run it, see Deployment options; to containerize it, see Building a Dockerfile.

Relocatable builds

A manifest holds no absolute paths — artifacts are written relative to the out-dir, sources relative to the project root — so you can build in one place and run in another. Build in a CI stage, copy .mochi/ into the final image, and point the runtime at wherever it landed:

Mochi.serve({ outDir: './.mochi' }); // default — or wherever you copied it

Paths resolve against the manifest’s own directory, so pointing manifest at a relocated build works on its own:

Mochi.serve({ manifest: '/srv/app/build/manifest.json' });

Persistent image cache

Mochi’s image cache is written to disk under cacheDir (default ./.mochi/image-cache). In a container that directory is recreated on every restart, so each redeploy starts with a cold cache and re-fetches and re-transforms every image. To keep the transformed bytes across restarts, point cacheDir at a dedicated path and mount a volume there:

Mochi.serve({
  image: { cacheDir: process.env.MOCHI_IMAGE_CACHE_DIR /* , sizes: … */ },
});

services:
  site:
    image: your-app
    environment:
      MOCHI_IMAGE_CACHE_DIR: /data/image-cache
    volumes:
      - image-cache:/data/image-cache

volumes:
  image-cache:

A plain docker run -v image-cache:/data/image-cache your-app mounts the same volume. Keep the mount off ./.mochi — its build cache is rebuilt on every boot and must not persist. If the container runs as a non-root user, pre-create the directory owned by that user in your Dockerfile so the mounted volume is writable.