elements
Manual Getting Started Deploy, Licensing, Support

Deploy, Licensing, Support

elements man start/deploy Read as markdown

Shipping the app, how load balancing works, and where to get help.

Deploy

Deploy to any Ubuntu Linux box with SSH access. Elements provisions the machine on first deploy (installs elements, creates a system user, sets up systemd, installs the license, configures the load balancer, provisions SSL, and brings up the bundled Postgres cluster).

Deploys are fast and safe. They run peer-to-peer, your project server talking directly to the deploy machine's, so only changed files transfer and rebuild: a cold deploy takes a few seconds, a hot one a few hundred milliseconds. Each machine stages the new release, runs the full build (compile, tests, migrations), and swaps it in with an atomic rename only after everything succeeds, so the previous release keeps serving until the new one is ready and a failed deploy leaves the running app untouched. Any failure (a compile error, a test failure, a migration failure) stops the release, and the cutover is coordinated across every machine, so if one fails none cut over and the whole cluster stays on the current release.

You need SSH access (root or sudo user) and the machine's public and private IP addresses. Add the machine to config.jsoc:

config.jsoc
{
  deploy: {
    domain: "example.com",
    ssh: {
      user: "root",
      identityFile: "~/.ssh/id_ed25519",
    },
    env: {
      production: {
        machines: [
          { name: "production0", publicIp: "203.0.113.10", privateIp: "10.0.0.10" },
        ],
      },
    },
  },
}

Then:

Terminal
elements deploy             # production by default
elements deploy staging     # named env
elements ssh production      # shell in /elements/app on the first production machine

The deploy machine runs the same bundled Postgres cluster as development. The scaffolded config.jsoc defaults host to env("DB_HOST", "127.0.0.1") and production.env sets DB_HOST=127.0.0.1, so a deploy uses the bundled cluster with no extra setup. Point at a remote database by setting DB_HOST (and the other DB_* values) in production.env.

Several machines share one Postgres cluster through DB_HOST, and every feature works across all of them with no other change: live tables, channels, sessions, jobs, and cron. A write on any app server reaches watching browsers on every app server. Uploaded files go in Postgres, where every machine reads them, or in S3 or any object store.

Deploy runs the same build as elements build, and a deploy ships once the local build is clean. The [host] tag on a diagnostic identifies which machine the error came from; no [host] means the local machine. Full topic: elements man deploy.

Load Balancing

Every app server runs a built-in load balancer; no separate appliance, no config file. Each reads the same config.jsoc and reloads on new builds. Every machine knows the others, so any one can front the cluster: point DNS at one or all public app servers and requests balance round-robin across machines, with failover when one is unreachable. SSL is issued and renewed through Let's Encrypt for every configured domain. A static maintenance page serves only when every machine is down. Full topic: elements man deploy.

Licenses on Deploy Machines

Every machine you deploy to needs a license, from the same account as the machine running elements deploy. Deploy takes care of it: before it builds, it checks out a license on each deploy machine from that account's pool. A machine that already has one keeps it.

If the pool has no license available, the deploy fails with a license error. Free a license from a machine you no longer use, or add licenses with elements purchase. To free one, check it in from your account page at https://elements.dev/account, which is usually easier, or run elements license checkin on that machine.

To license deploy machines from a different account, set license in the deploy config to that account's token.

Full topic: elements man licenses.

Support