Over a million developers have joined DZone.

Building and Deploying Scala Apps

DZone 's Guide to

Building and Deploying Scala Apps

If you've only ever tooled around with Scala in an IDE, here's a quick and easy way to see your app out in the Linux/Mac/Windows worlds.

· Java Zone ·
Free Resource

Hey! Looks like you're familiar with Scala. And I believe you've even developed some apps locally using it. One of coding's main missions is to help people to solve their problems. But how can your apps do this if they are running locally on your laptop? In this post, I want to show the easiest way to deploy a Scala application.

How to Build a Scala Project

What do I mean by saying “build” a Scala project? Well, it means that the project, running locally from the IDE, should be “transformed” into something that can be launched from any other environment (Linux / Windows / Mac).

Let’s consider a sample Scala project. It should be something really simple, so I decided to create a trivial akka-http app. Here is its structure:

Image title

I used green arrows in order to highlight the files that are important in the context of this article. By walking through the files, we can see what they contain and their purpose. By doing this, I want to work from a particular example to more general one.

Almost all Scala projects start from a build.sbt file. As a rule, it contains meta information about the project: name, version, dependencies…

name := "sbt-build-example"

version := "1.0"

scalaVersion := "2.12.2"

libraryDependencies ++= Seq(
  "com.typesafe.akka" %% "akka-http" % "10.0.9"

Take a look at the dependencies in the code above. To be more precise, look at the single dependency. For sure, your project contains more than one. But for this demonstration, it’s enough.

Then we have a Main class where all “business logic” happens:

package com.example

import akka.actor.ActorSystem
import akka.http.scaladsl.Http
import akka.http.scaladsl.Http.ServerBinding
import akka.http.scaladsl.server.Directives._
import akka.stream.ActorMaterializer

import scala.concurrent.Future

object Main extends App {

    implicit val system = ActorSystem()
    implicit val ec = system.dispatcher
    implicit val materializer = ActorMaterializer()

    val routes = pathPrefix("ping") {
        get {

    val bindingFuture: Future[ServerBinding] = Http().bindAndHandle(routes, "", 5000)


So the demo app has only one endpoint, which returns “pong” when you make a GET request to

You can check it if you want.

So, how to build this app? How to make it deployable? In order to perform this, we need to add the sbt-native-packager plugin to the project. You can do it by adding a single line of code to the plugins.sbt file.

addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.2.0")

Then you need to add the following line of code to the build.sbt file as well:



Open Terminal/your console, navigate to the root folder of the project, and execute the following command:

sbt stage

This command generates a new folder in your project directory: target/universal/stage/

There are two folders in the stage directory: bin and lib. The first one contains launchers (Linux/Mac/Windows). The second one contains all dependencies and a JAR with the application classes.

What’s next? As you may guess, the content of the stage directory can be moved to your server and launched there by executing the following command in the console:


Notice that this command must be run from the stage folder. By the way, app-name may vary. It depends on the project name (package name) that you specified in the build.sbt file.


As you can see, sbt-native-packager gives a pretty straightforward way to build a Scala project. What is really cool is that it provides more packaging options for Scala apps. In this article, I described only about 5% of the functionality that this plugin can perform. Therefore, I’m going to write a couple of new tutorials about sbt-native-packager.

java ,scala ,sbt-native-packager ,app deployment ,tutorial

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}