Meteor

Quave ONE is built by long-time Meteor contributors. We run Meteor applications on maintained, open-source Meteor Docker images and provide a Docker Preset to get started quickly.

Use a Dockerfile for ongoing deployments

For a production Meteor app, keep a Dockerfile in your repository. This is the recommended setup after your first deployment.

A Dockerfile makes the Meteor release, the build image, and the runtime image one versioned change. Review it with the application code, merge it together, and deploy it together. You do not have to coordinate a dashboard preset edit with the code release, and the deployed version is visible in Git history.

Docker Presets are useful for creating an app or generating a starting Dockerfile. They are not the preferred way to manage recurring Meteor upgrades.

Recommended Dockerfile

Start with the current Meteor preset, then save the result as Dockerfile in your repository. Keep the two image tags aligned with the Meteor version in .meteor/release.

FROM zcloudws/meteor-build:3.5.1 AS builder

WORKDIR /app-source/source
USER root
RUN chown zcloud:zcloud -R /app-source
USER zcloud

COPY --chown=zcloud:zcloud . /app-source/source
ENV METEOR_DISABLE_OPTIMISTIC_CACHING=1

RUN meteor npm --no-audit install \
  && meteor build --directory ../app-build

FROM zcloudws/meteor-node-mongodb-runtime:3.5.1-with-tools
COPY --from=builder /app-source/app-build/bundle /home/zcloud/app

RUN cd /home/zcloud/app/programs/server \
  && chmod +rw npm-shrinkwrap.json \
  && npm --no-audit install

WORKDIR /home/zcloud/app
ENTRYPOINT ["/scripts/startup.sh"]

The example uses Meteor 3.5.1. When you upgrade, change both image tags to the exact same supported version as your app. See the image README for available variants and options.

Upgrade Meteor: one change, one deployment

Do the upgrade in your application repository first, preferably on a branch and with your normal tests.

1. Update the app to the desired Meteor release, including .meteor/release. Follow Meteor's release notes for any application migration steps.
2. Run meteor update --npm locally when the release requires it, then install and test your dependencies. Commit every resulting project change, including lockfiles and any required configuration such as rspack.config.js.
3. Update the build image and runtime image in your Dockerfile to the same exact Meteor version.
4. Commit the application upgrade and Dockerfile update together, then deploy that commit to Quave ONE.
5. Check the build and application logs after the deployment.

Do not change only one side. A new build image with an older application, or an updated application with older build/runtime images, is an incompatible combination and can fail during the build.

Why this avoids preset coordination

Quave ONE releases Meteor images deliberately after they are built and validated. A newly released Meteor version can therefore be available in your project before it appears as a selectable Docker Preset. With a repository Dockerfile, you can use the supported image tag when it is ready without waiting for a UI preset entry, and the choice remains tied to the application commit.

If you use a Docker Preset

Quave ONE reads .meteor/release when connecting a repository and can select a matching Meteor Docker Preset. Use this flow only if you intentionally keep build configuration in Quave ONE:

1. Upgrade and commit the Meteor application first.
2. Select the matching preset version in the app settings.
3. Do not click Apply Changes just to upgrade Meteor. The preset selection is applied by the next deployment of the compatible code.
4. Deploy the commit that contains the matching application upgrade.

Applying a newer preset before deploying compatible source code can cause Quave ONE to build the older application with the newer Meteor image. If a matching preset is not listed, use a repository Dockerfile or contact support; do not substitute a different version.

Meteor settings

The Meteor images render the value of the METEOR_SETTINGS environment variable as your Meteor settings file. Provide the contents of settings.json as the variable value.

Paste your Galaxy settings

Migrating from Galaxy (Meteor Cloud)? Paste your settings into METEOR_SETTINGS. Quave ONE separates environment variables from the remaining Meteor settings so you can move the configuration without manually splitting it first.

Watch Filipe's video for a demonstration.

Existing custom Dockerfiles

The Meteor Dockerfile template uses /app-source as its working directory. If a custom Dockerfile was copied from an older template, replace these paths:

Old path	New path
/build/source	/app-source/source
/build/app-build	/app-source/app-build

Sticky sessions

Meteor apps should enable Sticky Sessions, because connected clients maintain session state.

APM

MontiAPM is a Meteor-focused APM. Quave ONE customers receive 10% off for the first six months through this link.

Existing MontiAPM accounts have seven days to activate the offer.