-
-
Notifications
You must be signed in to change notification settings - Fork 90
Deploying
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.
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
.
You can deploy to Heroku with the button below:
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.