npm install -g mup
mup should be installed on the computer you are deploying from. Node 8 or newer is required.
cd my-app-folder
mkdir .deploy
cd .deploy
mup init
WARNING: Windows users need to use mup.cmd instead in Command Prompt, as mup will result in unexpected behavior.
This will create two files in your Meteor Up project directory:
mup.js - Meteor Up configuration filesettings.json - Settings for Meteor’s settings APIJust the required and most common options.
module.exports = {
servers: {
one: {
host: '1.2.3.4',
username: 'root',
pem: '~/.ssh/id_rsa'
}
},
app: {
name: 'Wekan',
path: '../',
docker: {
image: 'abernix/meteord:base'
},
servers: {
one: {}
},
buildOptions: {
serverOnly: true
},
env: {
ROOT_URL: 'http://app.com',
MONGO_URL: 'mongodb://localhost/meteor'
}
},
mongo: {
version: '3.4.1',
servers: {
one: {}
}
}
};
module.exports = {
servers: {
one: {
host: '1.2.3.4',
username: 'root',
// pem: '/home/user/.ssh/id_rsa',
// password: 'password',
// or leave blank to authenticate using ssh-agent
opts: {
port: 22
},
// IP Address on a private network (optional)
// Used by some features (for example, load balancing)
// for communication between the servers
privateIp: '2.3.4.5'
},
two: {
host: '5.6.7.8',
username: 'root',
pem: '~/.ssh/id_rsa'
},
three: {
host: '2.3.4.5',
username: 'root',
password: 'password'
}
},
// Formerly named 'meteor'. Configuration for deploying the app
app: {
name: 'app',
path: '../app',
// (optional, default is meteor) Plugins can provide additional types
type: 'meteor',
// lets you add docker volumes (optional). Can be used to
// store files between app deploys and restarts.
volumes: {
// passed as '-v /host/path:/container/path' to the docker run command
'/host/path': '/container/path',
'/second/host/path': '/second/container/path'
},
docker: {
// Change the image to 'kadirahq/meteord' if you
// are using Meteor 1.3 or older
image: 'abernix/meteord:base',
// lets you add/overwrite any parameter on
// the docker run command (optional)
args: [
// linking example
'--link=myCustomMongoDB:myCustomMongoDB',
// memory reservation example
'--memory-reservation 200M'
],
// (optional) It is set to true when using a docker image
// that is known to support it. Builds a new docker image containing the
// app's bundle and npm dependencies to start the app faster and
// make deploys more reliable and easier to troubleshoot
prepareBundle: true,
// (optional, default is false) Uses the new docker image builder
// during Prepare bundle. When enabled,
// Prepare Bundle is much faster
useBuildKit: true,
// Additional docker build instructions, used during Prepare Bundle
buildInstructions: [
'RUN apt-get update && apt-get install -y imagemagick'
],
// (optional, default is true) If true, the app is stopped during
// Prepare Bundle to help prevent running out of memory when building
// the docker image. Set to false to reduce downtime if your server has
// enough memory or swap.
stopAppDuringPrepareBundle: true,
// lets you bind the docker container to a
// specific network interface (optional)
bind: '127.0.0.1',
// lets you add network connections to perform after run
// (runs docker network connect <net name> for each network listed here)
networks: [
'net1'
]
},
// list of servers to deploy to, from the 'servers' list
servers: {
one: {},
two: {},
three: {
// Add or override env variables for specific servers (optional)
env: {
PORT: 5000
}
}
},
// All options are optional.
buildOptions: {
// Set to true to skip building mobile apps
// but still build the web.cordova architecture. (recommended)
serverOnly: true,
// Set to true to disable minification and bundling,
// and include debugOnly packages
debug: false,
// defaults to a a folder in your tmp folder.
buildLocation: '/my/build/folder',
// Remove this property for mobileSettings to use your settings.json
mobileSettings: {
yourMobileSetting: 'setting value'
},
// your app url for mobile app access
server: 'http://app.com',
// When true, adds --allow-incompatible-updates arg to build command
allowIncompatibleUpdates: false,
// Executable used to build the meteor project
// You can set to a local repo path if needed
executable: 'meteor'
},
env: {
// If you are using SSL, this needs to start with https
ROOT_URL: 'http://app.com',
// When using the built-in mongodb,
// this is overwritten with the correct url
MONGO_URL: 'mongodb://localhost/meteor'
// The port you access the app on. (optional, default is 80)
// PORT: 8000
// The number of proxies in front of your server (optional, default is
// 1 with reverse proxy, unused otherwise).
// https://docs.meteor.com/api/connections.html
// HTTP_FORWARDED_COUNT: 1
},
// Docker log options (optional)
log: {
driver: 'syslog',
opts: {
'syslog-address': 'udp://syslogserverurl.com:1234'
}
},
// The maximum number of seconds it will wait
// for your app to successfully start (optional, default is 60)
deployCheckWaitTime: 60,
// lets you define which port to check after the deploy process, if it
// differs from the meteor port you are serving
// (like meteor behind a proxy/firewall) (optional)
deployCheckPort: 80,
// Shows progress bar while uploading bundle to server
// You might need to disable it on CI servers
// (optional, default is false)
enableUploadProgressBar: true
},
// (optional) Use built-in mongodb. Remove it to use a remote MongoDB
mongo: {
// (optional, default is 3.4.1) Version of MongoDB
version: '3.4.1',
// (optional, default is the name of the app)
dbName: 'maps',
// (optional, default is /var/lib/mongodb) Folder to store the mongodb data
dataPath: '/var/lib/mongodb',
servers: {
one: {}
}
}
};
mup setup
Running this locally will set up the remote servers you have specified in your config. It will take around 2-5 minutes depending on the server’s performance and network availability.
It is safe to run mup setup multiple times if needed. After making changes to custom SSL certificates, MongoDB, or servers in your config, you need to run mup setup for the changes to take effect.
mup deploy
This will bundle the Meteor project locally and deploy it to the remote server(s). The bundling process is the same as what meteor deploy does.
mup deploy --cached-build
The --cached-build option will use the build from the last time you deployed the app. This is useful when the previous deploy failed from a network error or from a problem in the config.
mup reconfig - reconfigures app with new environment variables, Meteor settings, and it updates the start script. This is also the last step of mup deploy.mup stop - stop the appmup start - start the appmup restart - restart the appmup logs [-f --tail=50] - view the app’s logs. Supports all of the flags from docker logs.Mup supports Meteor 1.2 and newer, though you might need to change the docker image in your mup config.
| Meteor version | Docker image | Prepare Bundle | Notes |
|---|---|---|---|
| 1.2 - 1.3 | kadirahq/meteord |
false | This is the default docker image. When using Meteor 1.2, app.buildOptions.serverOnly should be false. |
| 1.2 - 3.0 and newer | zodern/meteor:root |
true | Automatically uses the correct node version for the app’s Meteor version. |
| 1.4 - 1.5 | abernix/meteord:node-4-base |
true | |
| 1.6 - 1.8 | abernix/meteord:node-8-base |
true | |
| 1.9 - 2.2 | abernix/meteord:node-12-base |
true |
When using an image that supports Prepare Bundle, deployments are easier to debug and more reliable.
You can define Meteor build options in mup.js like this:
...
app: {
buildOptions: {
// Set to true to disable minification and bundling,
// and include debugOnly packages
debug: false,
// mobile setting for cordova apps
mobileSettings: {
public: {
'meteor-up': 'rocks',
}
},
// executable used to build the meteor project
// you can set a local repo path if needed
executable: 'meteor',
}
}
...
Meteor Up checks if the deployment is successful or not just after the deployment. It will wait 15 seconds after starting the docker container before starting the checks. The check runs every second until it either can successfully load the app’s client, or it runs out of time as defined in app.deployCheckWaitTime.
If you are deploying under a proxy/firewall and need a different port to be checked after deploy, add a variable called deployCheckPort with the value of the port you are publishing your application to.
app: {
...
deployCheckPort: 80
...
}
This only tested with Mac/Linux
It’s common to use passphrase enabled SSH keys to add an extra layer of protection to your SSH keys. You can use those keys with mup too. In order to do that, you need to use ssh-agent.
Here’s the process:
pem field from mup.js so your mup.js has username and host only.eval $(ssh-agent)ssh-add <path-to-key>mup commands and they’ll just workssh-agent -ksudoIf your username is root or you’re using AWS EC2, you don’t need to follow these steps
Please ensure your key file (pem) is not protected by a passphrase. This setup process will require NOPASSWD access to sudo.
Make sure you also add your ssh key to the /YOUR_USERNAME/.ssh/authorized_keys list.
You can add your user to the sudo group:
sudo adduser *username* sudo
And you also need to add NOPASSWD to the sudoers file:
sudo visudo
# replace this line
%sudo ALL=(ALL) ALL
# by this line
%sudo ALL=(ALL) NOPASSWD:ALL
When this process is not working you might encounter the following error:
'sudo: no tty present and no askpass program specified'
Meteor Up uses Docker to run and manage your app. It uses MeteorD behind the scenes. Here’s how we manage and utilize the server.
/opt/<appName>/current--restart=always flag and it’ll re-spawn the container if it dies27017 (you cannot access it from the outside)<appName>Add all of the servers to the servers object and modify app.servers to include them.
To deploy to different environments (e.g. staging, production, etc.), use separate Meteor Up configurations in separate directories, with each directory containing separate mup.js and settings.json files, and set the app.path field in each config to point back to your app’s directory.
Meteor Up supports multiple deployments to a single server. To route requests to the correct app, use the reverse proxy.
Let’s assume we need to deploy production and staging versions of the app to the same server. The production is at myapp.com, and staging is at staging.myapp.com.
We need to have two separate Meteor Up projects. For that, create two directories, initialize Meteor Up, and add the necessary configurations.
In the staging mup.js, change the field app.name to have the value staging. You can add any name you prefer instead of staging.
Next, add the proxy object to both configs. For your production app, it would be:
module.exports = {
// ... rest of config
proxy: {
domains: 'myapp.com'
}
};
For the staging app, proxy.domains would be staging.myapp.com.
Now, set up both projects and deploy the apps.
During Prepare Bundle, mup builds a new docker image that includes your app’s code. You can customize this image by adding additional build instructions that are run before adding your app. This can be used to install dependencies your app needs, such as adding imagemagick or node-canvas’s dependencies.
You can add instructions with app.docker.buildInstructions. An example is:
module.exports = {
app: {
name: 'app',
path: '../',
servers: { one: {} },
docker: {
buildInstructions: [
'RUN apt-get update && apt-get install -y imagemagick'
]
}
}
};
Each item is added on a new line in the Dockerfile, and should start with RUN, USER, or another dockerfile instruction.
If the base docker image runs the app as a non-root user, you might need to switch the user to root for your RUN commands, and back to the non-root user afterwards.
After changing the config, run mup deploy.
All files created inside of the app’s docker container are lost when the app crashes, is deployed, or restarted. To persist certain folders, you can use the app.volumes option. For example:
module.exports = {
app: {
name: 'app',
path: '../',
servers: { one: {} },
volumes: {
'/opt/images': '/images'
}
}
};
Any files stored in /images by the app inside the docker container will persist between restarts and deploys. The files will also be available on the server at /opt/images.
Normally, mup uploads the app’s bundle and builds a docker image (when prepare bundle is enabled) on each server, which is slow when there are many servers. When using a private docker registry, it is much faster:
To use a private registry, add the dockerPrivateRegistry option to your config:
module.exports = {
// ... rest of config
privateDockerRegistry: {
username: 'username',
password: 'password',
// (optional) Hostname of registry. If not provided, defaults to the
// docker hub registry
host: 'registry.domain.com',
// (optional) The image name will start with this value.
imagePrefix: 'image-name-prefix-'
}
};
The image name is mup-${app name}. When an image prefix is supplied, the image is named ${imagePrefix}/mup-${app name}.
Some registries, such as Gitlab’s or Google Cloud’s, require image names to start with a certain string. For example, the prefix for Google Cloud would be eu.gcr.io/<project id>, and for GitLab it would be registry.gitlab.com/<group name>/<project name>.
If you want Docker to listen only on a specific network interface, such as 127.0.0.1, add a variable called bind with the value of the IP address you want to listen to.
app: {
...
docker: {
...
bind: '127.0.0.1'
...
}
}
If you need to connect your docker container to one or more networks add a variable called networks inside the docker configuration. This is an array containing all network names to which it has to connect.
app: {
...
docker: {
...
networks: [
'myNetwork1'
]
...
}
...
}
Simply reference the docker image by url in the app.docker.image setting:
app: {
...
docker: {
...
image: 'registry.gitlab.com/someregistry/someimage:sometag'
}
}
And then add a docker setup hook to login to your private registry on the server. See Hooks for example of logging into a private docker registry.
You can set app.docker.imagePort to the port to expose from the container. This does not affect the port the app is accessed on, only the port the app runs on inside the docker container. It defaults to 3000.
Meteor Up can create a nginx reverse proxy that will handle SSL, and, if you are running multiple apps on the server, it will route requests to the correct app. The proxy is shared between all apps on the servers.
This replaces the former nginx setup, configured using app.ssl and app.nginx.
Remove app.ssl and app.nginx from your config and add a proxy section:
module.exports = {
// ... rest of config
proxy: {
// (Required when using swarm) Servers to run the reverse proxy on.
// When using Let's Encrypt, DNS needs to be setup for these servers.
servers: {
one: {}
},
// comma-separated list of domains your website
// will be accessed at.
// You will need to configure your DNS for each one.
domains: 'website.com,www.website.com'
}
};
The first time you setup the reverse proxy, you need to stop every app running on the servers:
mup stop
Then, run
mup setup
mup reconfig
Mup is able to load balance your app across multiple servers with sticky sessions.
Set proxy.loadBalancing to true in your config:
module.exports = {
// ... rest of config
proxy: {
domains: 'website.com',
loadBalancing: true,
// Use sticky sessions when load balancing (optional, default is true)
stickySessions: true
}
};
Then run mup setup and mup reconfig.
So nginx can access the app on other servers, the app will be publicly accessible on a random port between 10,000 and 20,000. If you set the privateIp for the servers, it will only be accessible on the private network.
The random port does not change across deploys. It will always be the same port for an app with the same name. If you use a firewall to whitelist open ports, run mup validate --show and look at app.env.PORT to see which port to open.
In the future, mup will be able to configure a firewall so only the servers running nginx can access the app.
Add an ssl object to your proxy config:
module.exports = {
// ... rest of config
proxy: {
domains: 'website.com,www.website.com',
ssl: {
// Enable let's encrypt to create free certificates.
// The email is used by Let's Encrypt to notify you when the
// certificates are close to expiring.
letsEncryptEmail: 'email@domain.com'
}
}
};
For Let’s Encrypt to work, you also need to:
app.env.ROOT_URL starts with https://proxy.domains to point to the serverFull or Full (strict)After changing the config, run mup setup and mup reconfig. It will automatically create the certificates and setup SSL, which can take up to a few minutes. The certificates will be automatically renewed when they expire within 30 days.
If you are using custom certificates instead, it would look like:
module.exports = {
// .. rest of config
proxy: {
domains: 'website.com,www.website.com',
ssl: {
crt: './bundle.crt',
key: './private.pem'
}
}
};
Then run mup setup.
You can view the list of certificates and when they expire by running mup status.
In your config, add:
module.exports = {
// ... rest of config
proxy: {
domains: 'website.com,www.website.com',
ssl: {
forceSSL: true
}
}
};
It uses HSTS. This means that if you set it to false after it’s been true, the browser used by anyone that visited it while it was set to true will still be redirected to https for one year.
The nginx config is generated based on the docker containers running on the same server. At this time, it is not possible to modify the majority it. However, you can modify the server and / location blocks for the app. It is also possible to add a config that is used proxy-wide, and can add additional upstream and server blocks.
To extend the server block for the app, save the rules to a file and add the path to your config:
module.exports = {
// ... rest of config
proxy: {
domains: 'website.com',
nginxServerConfig: './path/to/config'
}
};
To modify the / location block, save the rules to a file and add the path to your config:
module.exports = {
// ... rest of config
proxy: {
domains: 'website.com',
nginxLocationConfig: './path/to/config'
}
};
To learn about the nginx config used proxy-wide, look at the proxy.shared example in the advanced configuration docs.
You can view the generated config by running
mup proxy nginx-config
There will be include statements for each custom config.
Due to planned reasons or unexpected problems, the reverse proxy or a server might be stopped or go down. To prevent this from causing downtime, you want other servers to handle serving requests.
This is not solved in mup, and we welcome ideas or pull requests to improve it.
When using lets encrypt, mup is currently not able to set it up for high availability due to the challenge of domain verification and updating certificates when there are multiple servers.
When not using SSL or when using custom certificates, you can run the reverse proxy on multiple servers with no problems.
To use a healthy instance to serve requests, you have two options
These are additional options that can be used to customize the reverse proxy. The defaults are compatible with most apps.
module.exports = {
// ... rest of config
proxy: {
domains: 'website.com,www.website.com',
// (optional, default=10M) Limit for the size of file uploads.
// Set to 0 disables the limit.
clientUploadLimit: '50M'
}
};
The proxy.shared object has settings that most apps won’t need to change, but if they are they apply to every app using the proxy. After you change proxy.shared, you need to run mup proxy reconfig-shared for it to take effect.
module.exports = {
// ... rest of config
proxy: {
domains: 'website.com,www.website.com',
// Settings in "proxy.shared" will be applied to every app
// deployed on the servers using the reverse proxy.
// Everything is optional.
// After changing this object, run `mup proxy reconfig-shared`
shared: {
// The port number to listen to for http connections. Default 80.
httpPort: 80,
// The port to listen for https connections. Default is 443.
httpsPort: 443,
// Add an nginx config that is used proxy-wide.
// This config can add additional upstream and server blocks if needed.
nginxConfig: './path/to/config',
// Environment variables for nginx proxy
env: {
DEFAULT_HOST: 'foo.bar.com'
},
// env for the jrcs/letsencrypt-nginx-proxy-companion container
envLetsEncrypt: {
// Directory URI for the CA ACME API endpoint
// (default: https://acme-v01.api.letsencrypt.org/directory).
// If you set it's value to
// https://acme-staging.api.letsencrypt.org/directory
// letsencrypt will use test servers that
// don't have the 5 certs/week/domain limits.
ACME_CA_URI: 'https://acme-v01.api.letsencrypt.org/directory',
// Set it to true to enable debugging of the entrypoint script and
// generation of LetsEncrypt certificates,
// which could help you pin point any configuration issues.
DEBUG: true
}
}
}
};
It’s okay to change app.name. But before you do so, you need to stop the project with the older appName. Also, if you use the built-in MongoDB, mup will create a new database with the new name so you will need to migrate the data.
mup stopmup setup and mup deployYou can keep multiple configuration and settings files in the same directory and pass them to mup using the command parameters --settings and --config. For example, to use a file mup-staging.js and staging-settings.json, add the parameters like this:
mup deploy --config=mup-staging.js --settings=staging-settings.json
This is depreciated. Use the reverse proxy to setup ssl instead.
Meteor UP can enable SSL support for your app. It can either autogenerate the certificates or upload them from your dev computer.
This is depreciated. Use the reverse proxy to setup ssl instead.
Meteor Up can use Let’s Encrypt to generate certificates for you. Add the following to your mup.js file:
app: {
...
ssl: {
autogenerate: {
email: 'email.address@domain.com',
domains: 'website.com,www.website.com'
}
}
}
You also need to:
app.env.ROOT_URL starts with https://app.ssl.autogenerate.domainsThen run mup deploy. It will automatically create certificates and set up SSL, which can take up to a few minutes. The certificates will be automatically renewed when they expire within 30 days.
This is depreciated. Use the reverse proxy to setup ssl instead.
To upload certificates instead of having the server generate them for you, just add the following configuration to your mup.js file.
app: {
...
ssl: {
crt: './bundle.crt', // this is a bundle of certificates
key: './private.key', // this is the private key of the certificate
port: 443 // 443 is the default value and it's the standard HTTPS port
}
...
}
Now simply do mup setup and then mup deploy. Your app is now running with a modern SSL setup.
If your certificate and key are already in the right location on your server and you would like to prevent Mup from overriding them while still needing an SSL setup, you can add upload: false in the app.ssl object.
To learn more about SSL setup when using your own certificates, refer to the mup-frontend-server project.
This is depreciated. Use the reverse proxy to configure this instead.
This Only Works if you are using the Let’s Encrypt Autogenerated SSL’s
If you would like to increase the client upload limits, you can change it by adding:
app: {
...
nginx: {
clientUploadLimit: '<desired amount>' // Default is 10M
}
...
}
To use an external database:
mongo object from your configapp.env.MONGO_URL to point to the external Mongo instanceTwo popular Mongo DbaaS’s are Compose and mLab.
Meteor Up can start a MongoDB instance on the server and set app.env.MONGO_URL to connect to it.
It is recommended to use an external database instead of the one built-in to mup for apps in production. The built-in database is not easy to backup, and only works when the app is running on one server.
Add the mongo object to your config:
module.exports = {
// .. rest of config
mongo: {
version: '3.4.1',
servers: {
one: {}
}
}
};
To use the oplog, set app.env.MONGO_OPLOG_URL to mongodb://mongodb/local.
Before your first setup, it is recommended to change mongo.version to the newest version of MongoDB your app or meteor supports. After Mongo is started, it is more complex to upgrade it.
After you finished changing the config, run
mup setup
and
mup deploy
All apps on a server share the same Mongo instance, but by default each app uses a different database, named after the app’s name.
For multiple apps to use the same database, use the mongo.dbName option. All apps using this database should have the exact same mongo config.
module.exports = {
mongo: {
version: '3.4.1',
dbName: 'staging',
servers: {
one: {}
}
}
};
You can’t access the MongoDB from outside the server. To access the MongoDB shell you need to log into your server via SSH first and then run the following command:
docker exec -it mongodb mongo <appName>
If you are experiencing problems with MongoDB (such as it frequently restarting), you can view the logs with
mup mongo logs
For backup you can use:
ssh root@host "docker exec mongodb mongodump -d <appName> --archive --gzip" > dump.gz
and for restore:
cat dump.gz | ssh root@host "cat | docker exec -i mongodb mongorestore --archive --gzip" # use --drop if you want to drop existing collections first
If you have not deployed to the server, you can change the mongo version by adding:
mongo: {
...
version: '<desired version>'
}
If you have deployed to the server, it involves a couple more steps.
docker exec -it mongodb mongo on the server.mup.js and run mup setup.docker ps to check if MongoDB keeps restarting. If it is, you can see what the problem is with docker logs mongodbMup can setup and manage a Docker Swarm cluster.
This feature is experimental. There could be backwards breaking changes and a larger number of bugs and problems. At this time, it is not recommended to use in production.
There are some requirements and restrictions. We plan to remove as many of these as possible over time.
server.<servername>.host in your config.app.docker.argsapp.ssl. The new reverse proxy should be used instead, and is required for load balancing and zero downtime deploys to work.To enable, first stop the app with mup stop and add swarm.enabled in your config:
module.exports = {
swarm: {
enabled: true
}
};
Then run mup setup and mup deploy.
For the reverse proxy to work correctly, set proxy.servers.
If you encounter problems with swarm, please create an issue. mup docker setup should fix most problems. If necessary, you can run mup docker destroy-cluster, mup setup, and mup startto recreate the swarm cluster, services, and networks, excluding any that you manually created.
If multiple apps are using swarm and sharing servers, their servers object should have the same servers. Since a config is a javascript file, you can have a separate file with the servers imported by the configs.
module.exports = {
swarm: {
enabled: true,
// Array of labels for mup to manage
labels: [
{
name: 'label-name',
value: 'label-value',
servers: [
'one'
]
}
]
}
};
You only need to read this section if you are planning to use a tool or manually make changes to the cluster (adding/removing nodes, managers, networks, services, labels, etc).
It is okay to add a node to the cluster. Instead of adding it to the swarm cluster manually, you can add it to the servers object in your config and run mup docker setup.
It is also okay to remove nodes. Make sure they are not being used in the config before removing them.
Mup manages which servers are managers. It is not recommended to manually promote nodes since Mup might revert the changes the next time mup setup is run. This is how mup decides which servers to make managers:
proxy.servers to be managersWhen adding more managers than listed by plugins, mup will try to keep existing managers.
It is okay to add networks. Some plugins create overlay networks. If you need those networks to have different settings, it is safe to recreate them with the same name.
You can create additional services. If you remove or update services created by mup, it will recreate them or revert the changes.
Plugins and swarm.labels in the config can provide a list of labels for mup to manage. Any changes to these labels (setting it for additional nodes, removing it, or changing its value) will be reverted. You can add, modify, or remove any other label.
Mup does not remove labels that plugins no longer use.
Hooks allow you to run a command or function before or after a CLI command is run. The config looks like:
const childProcess = require('child_process');
module.exports = {
hooks: {
hookName: {
localCommand: 'command to run on computer',
remoteCommand: 'command to run on every server'
},
'pre.deploy': {
localCommand: 'npm prune --production'
},
'post.meteor.restart': {
remoteCommand: 'docker logs --tail 50 app-name'
},
'pre.reconfig'(api) {
// Same api as is given to plugin command handlers
// If this runs asynchronous tasks, it needs to return a promise.
const gitHash = childProcess.execSync('git rev-parse HEAD').toString().trim();
api.getSettings();
api.settings.GIT_HASH = gitHash;
},
'post.docker.setup'(api) {
// Login to private Gitlab docker registry
const config = api.getConfig();
const registry = 'registry.gitlab.com';
const username = process.env.REGISTRY_USERNAME;
const password = process.env.REGISTRY_PASSWORD;
if (!username || !password) {
throw new Error(
'You must provide registry login details'
);
}
return api.runSSHCommand(
config.servers.one,
`docker login -u ${username} -p ${password} ${registry}`
);
}
}
};
The hook name format is {pre or post}.topLevelCommand.subCommand. For example, if you want a command to run after mup deploy, the hook name would be post.deploy. Or if you want it to run after mup mongo restart, the hook name would be post.mongo.restart.
Some CLI commands run other CLI commands. For example, mup setup runs mup docker setup and mup mongo setup. To see all of the available hooks while a command runs, use the --show-hook-names option.
To update mup to the latest version, just type:
npm install -g mup
mup usually will let you know when there is an update available. You should try and keep mup up to date in order to keep up with the latest Meteor changes.
After updating, run mup setup for all of your apps.
If you suddenly can’t deploy your app anymore, first use the mup logs -f command to check the logs for error messages.
You can also view logs for:
mup mongo logsmup proxy logsmup proxy logs-lemup status checks the servers for any potential problems, as well as shows you the status of any docker containers or services running on the servers.
Make sure that the docker image you are using supports your app’s meteor version.
Some problems are caused by old versions of docker. Since mup 1.3, mup setup and mup docker setup will update Docker if it is older than 1.13.
You can view a list of Docker containers with
mup docker ps
and check the STATUS column.
If you need to see the output of mup (to see more precisely where it’s failing or hanging, for example), run it like so:
DEBUG=mup* mup <command> --verbose
where <command> is one of the mup commands such as setup, deploy, etc.
The environment variable DEBUG=mup* gives more information on what the mup CLI is doing.
The --verbose flag shows output from commands and scripts run on the server.
If you do not see => Starting meteor app on port in the logs, your app did not have enough time to start. Try increase app.deployCheckWaitTime. This only applies if Prepare Bundle is disabled.
If you do see it in your logs, make sure your ROOT_URL starts with https or http, depending on if you are using SSL or not. If that did not fix it, create a new issue with your config and output from mup deploy --verbose.
If you are using Meteor 1.3, you might see this error:
/bundle/bundle/programs/server/node_modules/fibers/future.js:280
throw(ex);
^
ReferenceError: module is not defined
at app/mup.js:1:-27
This error happens when your config gets bundled with the app. Try moving it and your settings.json to a hidden folder (such as app/.deploy) or to a location outside of the app’s folder.
If you are using Command Prompt on Windows, make sure you run commands with mup.cmd <command> instead of mup <command>, or use PowerShell.
If it silently fails for a different reason, please create an issue.
Make sure meteor is installed on the computer you are deploying from.
Make sure your app.env.ROOT_URL starts with https://. Also, check that the DNS for all of the domains in ssl.autogenerate.domains is correctly configured to point to the server. Port 80 needs to be open on the server so it can verify that you control the domain.
You can view the Let’s Encrypt logs by running this command on the server:
docker logs <AppName>-nginx-letsencrypt
Replace <AppName> with the name of the app.
KilledThe server ran out of memory during npm install. Try increasing the server’s ram or creating a swap file.
Make sure force-ssl is not in .meteor/versions. If it is, either your app or a package it uses has force-ssl as a dependency.
mup is not backward compatible with Meteor Up 0.x. or mupx.
os.linux.x86_64 architecture. (This is the same thing what meteor-deploy does)Use a new server if you can. Then migrate DNS accordingly. That’s the easiest and safest way.
Let’s assume our appName is meteor
Remove old docker container with docker rm -f meteor
Remove old mongodb container with docker rm -f mongodb
If present remove nginx container with docker rm -f meteor-frontend
The new config format is different from mupx.
Run mup init to create a new config file.
Then do mup setup and then mup deploy.