Docker image

[IvanMTD]

If anyone needs it, I've built a Docker image here:
https://cdn.s3.mshart.ru/cloud/docker/images/pascal-editor.tar

Just download it, upload it to your server, and run:

text

docker load -i pascal-editor.tar
docker run -d --name pascal-editor -p 3002:3000 editor-editor:latest

And voilà :)

[Aymericr]

Thanks for sharing this, and for the clear load-and-run instructions.

Consolidating the container thread so people land in one place: this is the third Docker discussion (#263 asks for an official distribution, #183 documents a local quick-start) and #268 is the open PR that would make one official. I have linked them to each other so the context is not split four ways.

One caveat worth stating plainly for anyone who finds this thread: a .tar image hosted outside the project is not something we can vouch for. There is no way for a reader here to verify what is inside it or that it matches a specific commit, so please treat it as a community convenience rather than a Pascal release. Nothing about your intent — it is just the honest status of any third-party image.

If you would like this to become something people can trust, the useful next step is pushing your Dockerfile into #268 rather than distributing a prebuilt tarball. The gaps that PR still needs closed:

• a multi-stage build so the runtime layer does not carry the toolchain
• a non-root runtime user
• a HEALTHCHECK
• documented environment variables
• a verified Alpine install of the GitHub package dependency

Once those are in and the image builds from a tagged commit, we can publish it to GHCR from CI, which gets provenance and reproducibility for free. That is the path to the "official" answer #263 is asking for.

[Aymericr]

Following up: Docker support is on main now. #268 merged today, so this is no longer needed as a stopgap:

git clone https://github.com/pascalorg/editor.git
cd editor
docker compose up -d          # http://localhost:3000

Your tarball got people running months before that existed, and the load-and-run instructions were clear enough that they worked as written — thanks for that.

Two differences from your image worth flagging for anyone still using it:

Port. You mapped -p 3002:3000, which is the natural thing to do given the dev server runs on 3002. That remap breaks the /scenes page — it fetches its own API through a base URL only NEXT_PUBLIC_APP_URL can override, and Next inlines that at build time, so the page returns 500. The official compose keeps 3000:3000 for this reason. Reverse-proxy if you need a different external port.

Persistence. Saved scenes go to SQLite under PASCAL_DATA_DIR. Without a volume that file sits in the container layer and every project vanishes when the container is recreated, so docker run without -v loses work. The compose file sets PASCAL_DATA_DIR=/data against a named pascal-data volume.

Not asking you to take this down — just noting for anyone who finds the thread that the tarball has no persistence and a port mapping that breaks one page. And the general caveat I mentioned earlier stands: an image hosted outside the project can't be verified by us, so building from source is the path we can vouch for.

There's still an open piece if you're interested: no pre-built image is published to a registry yet, and the locally-built one is 5.33 GB because it keeps the full monorepo and dev dependencies. A multi-stage build plus a release workflow to push to ghcr.io would be a genuinely valuable follow-up, and you've already demonstrated you can build and ship one of these. The one constraint to know going in is in #263 — shrinking it wants output: 'standalone', which touches config shared with the hosted Vercel deploy, so it needs care rather than just being added.