Before making your application publicly available, you should choose a unique secret key to use to sign the session cookie. Keep this key a secret so that your users won't be able to forge a fake session.
The application secret key is defined by the application.secret configuration property. By default, the template sets it to
changeme. Note that if you try to run your application in the production mode while your secret key still has the changeme value, Play throws an exception.
We already saw how you can run your application in production mode using the start sbt command. This command compiles your code, eventually executes the assets pipeline if you use it, and starts the Play HTTP server in a new JVM.
However, the start command is executed within the sbt shell, which means that you actually have two running JVMs: one for sbt itself and one for your application. In addition to the start command, there also is a stage command that packages the application and creates an executable *nix shell script and a .bat script to start it. This script directly starts the Play HTTP server without relying on sbt. The script is located in the target/universal/stage/bin/<app-name> file (that is, for the shop application, it is located in the target/universal/stage/bin/shop file). Once an application has been staged, it can be started by executing the script and stopped by sending it a SIGTERM signal (this can be achieved by typing Ctrl + C on *nix systems).
Note
The stage command is not specific to Play; it is provided by an sbt plugin named native packager. As you will see in the next section, several cloud hosting systems rely on this plugin to manage sbt applications from their code source. They just invoke the sbt stage command when you deploy it on the cloud, and then they can run the application.
The approach using the stage command requires you to have sbt installed on the machine that runs the application. Alternatively, you can use the dist command to produce an archive of the packaged application and its starting scripts. You can then copy this archive to the server. The archive is located in a file named target/universal/stage/<app-name>-<version>.zip.
Several cloud platforms as a service provide built-in Play support (for example, Heroku or Clever Cloud). It is worth noting that most of them have free plans if your application handles a limited traffic. This can be very useful to publish a prototype on the Web without having to set up a server infrastructure.
The deployment process can vary from one system to the other, but the pattern is generally to send the application source code on the platform as a service. The platform then relies on the stage sbt command to produce the starting scripts and manage their execution for you. Finally, deploying on such a platform is usually as easy as performing a git push!
When this approach is not supported, the platform is usually able to run the application from the .zip output file of the dist command described in the previous section.
You probably want to use a different database in the dev and prod modes so that during development, you don't alter the production data. Often, it is very common to use different configuration settings in the dev and prod modes to make your development process safer and easier (for example, by populating your database with fake data).
The global object's method, onApplicationStart, is a good place to do some setting up at application bootstrap, but you probably don't want to do the same things for the dev and prod modes. You can distinguish between these modes by calling the Application's mode member (or the isDev and isProd methods in Java). Alternatively, you can use completely different global objects in the dev and prod modes by setting its fully qualified name in the application.global configuration property. For this to work, you need to be able to define different configuration settings in the dev and prod modes, though.
Configuration settings defined in the application.conf file can be overridden when you run the application, by supplying additional command-line arguments:
$ target/universal/stage/bin/shop –Dapplication.global=my.prod.GlobalObject
Alternatively, you can use distinct configuration files for the dev and prod modes. This can be achieved by supplying a config.resource configuration property:
$ target/universal/stage/bin/shop –Dconfig.resource=prod.conf
This will look for a prod.conf file in the project's classpath.
You can also use the config.file property to use a file that is on the machine's file system, or even config.url to specify a URL.