ReferenceEdit on GitHub

Deployment files#

What eezo build stages, what eezo deploy writes, and every field in the generated fly.toml. The staged files on this page are the bookshelf's.

target/eezo/stage/#

target/eezo/stage/
  Dockerfile
  db/
    migrations/
    schema.json
  lib/
    bookshelf_3-0.1.0-SNAPSHOT.jar
    eezo_3.jar
    eezo-auth_3.jar
    ...
  • lib/ holds every jar on the runtime classpath plus your own project packaged as one. Twenty-four for the bookshelf. Two jars with the same file name keep the first and prefix the next with a counter, 1-name.jar. A directory on the classpath that isn't your own classes, an internal module of a multi-project build, is skipped and logged at debug.
  • db/ is a copy of your db/, present even when you have none, so the Dockerfile's COPY never fails.
  • Dockerfile is regenerated on every stage.

The directory is deleted and rebuilt on every eezo build. Nothing in it is edited.

The Dockerfile#

# Generated by eezo (eezoStage). Regenerated on every stage; do not edit.
FROM eclipse-temurin:25-jre-noble
WORKDIR /app
COPY lib lib
COPY db db
# MaxRAMPercentage over a fixed -Xmx, because the platform decides the machine size.
ENTRYPOINT ["java", "-XX:MaxRAMPercentage=75", "-cp", "lib/*", "Main"]
linewhy
FROM eclipse-temurin:<eezoJavaVersion>-jre-noblea JRE, no JDK, no sbt
WORKDIR /appthe migration runtime resolves db/ against the working directory
COPY db dbso migrate --apply in the image finds the files freeze wrote
MaxRAMPercentage=75the heap follows the machine size
ENTRYPOINT, not CMDa platform's release command replaces CMD and keeps the entrypoint, so migrate --apply becomes arguments to your main

Main is Compile / run / mainClass, and staging fails with a message when the build has none.

fly.toml#

Written once, on the first deploy, after fly launch has created the app, with the name and region that fly launch chose; the two below are examples. Yours after that: commit it, edit it, and eezo rewrites it only if you delete it.

# Generated by eezo deploy. Yours to edit; eezo rewrites it only if you delete it.
app = 'bookshelf'
primary_region = 'fra'

[deploy]
  # Runs in a one-off machine with the NEW image, before any app machine is updated. A nonzero
  # exit stops the deployment and the old version keeps serving — this is eezo's migration
  # ordering: the schema converges before new code takes traffic.
  release_command = 'migrate --apply'

[http_service]
  # Must match the app's `port` (EezoApp default: 8080).
  internal_port = 8080
  force_https = true
  auto_stop_machines = 'stop'
  auto_start_machines = true
  min_machines_running = 0

  [[http_service.checks]]
    grace_period = '10s'
    interval = '15s'
    timeout = '5s'
    method = 'GET'
    path = '/eezo/health'
fieldvaluechange it when
appthe name fly launch chose or --app gavenever
primary_regionthe region fly launch pickedyou want another
release_commandmigrate --applythe application has no database layer; delete the [deploy] block
internal_port8080your Main overrides port
force_httpstrue
auto_stop_machines, min_machines_runningstop, 0the application has live pages: set min_machines_running = 1, or an idle stop closes every socket
the checkGET /eezo/health every 15 snever; it's the framework's endpoint

What is never written#

Secrets. EEZO_SECRET and the database variables go through fly secrets set, and fly postgres attach sets DATABASE_URL. eezo deploy checks that a DATABASE_URL or EEZO_DB_URL secret exists before deploying an application with migrations, by name only.

Settings#

settingdefaulteffect
eezoJavaVersion"25"the tag of the base image
Compile / run / mainClasssbt's choicethe entrypoint's class

Deploying is the recipe. Deployment is why the files look like this.