Skip to content

Deploying

Gareth Latty edited this page May 3, 2020 · 14 revisions

Configuration

The configuration file is config.json5 and should be well documented on the options contained. The defaults should be reasonable, except in a live environment you will need to set secret to a real value. You can run npm run generate-secret in the server project to generate an appropriate value.

There are two implementations for both storage and caching: in-memory and using a PostgreSQL database. There are trade-offs to both, but the biggest difference is that with database backing games will survive server restarts. Normally this isn't very important as games are short-lived, but it may be in your case.

Please note that you will need PostgreSQL 12 or newer. If you are using docker to deploy, the postgres:12 image should do the job well, and Heroku support 12 on their PostgreSQL service.

If you would like to customise the built-in decks or enable/disable sources of decks, please see the the built-in decks page.

Application

Docker

The quickest and easiest way to deploy a build of Massive Decks is to use the docker images.

If you are happy to use the prebuilt images, you can use a docker_compose.yml that looks something like one of the examples in the deployment folder.

The project contains a docker-compose.yml which can be used to build both images from scratch and run them for development. Please do not try and use this as-is for a production deployment, instead use a setup that at least correctly sets NODE_ENV and MD_SECRET.

Heroku

You can deploy to Heroku with the button below:

Deploy to Heroku

Manually

There are two core components to Massive Decks - the client and the server. The server is an node application. To build it do npm run build in the server directory. Then you can then take the compiled application in dist and run node --es-module-specifier-resolution=node index.js. Note that this server is not intended to be public-facing. You should always have a more robust reverse-proxy in front of it.

The client is an Elm application. This can again be built with npm run build (this time from the client directory). The result will be static files in dist you must then serve.

In general, you can kill two birds with one stone and serve the static files while reverse proxying the game server with the same public web server (this is what the docker images do). See nginx.conf in the client project for an example of how nginx can be configured for this task - it should be easy enough to adapt for other servers.

Clone this wiki locally