Skip to content
All posts
2 min readtebakopackagingtutorial

Basic payloads: Package a Rails or Sinatra application (4 of 5)

The basic payloads series, hands-on: package a rails or sinatra application.

The Tebako team

github.com/tamatebako
Note

Post 4 of 5 in the series Basic payloads.

○ ○ ○ ● ○

  1. Basic payloads: Run your first package

  2. Basic payloads: Data payloads: make one, read one

  3. Basic payloads: Package a Ruby application

  4. Basic payloads: Package a Rails or Sinatra application (this post)

  5. Basic payloads: Publish to your users
Note

Reference guide: Package a Ruby app.

A web application is an application whose entrypoint starts a server. That is the whole trick: press the app so that running the executable serves HTTP. This post’s subject is packaging Rails and Sinatra applications, and the few decisions that are specific to them.

Package a web application the packaged web application a browser http://localhost:3000 your packaged app the server entrypoint: puma or rackup app code · gems · assets — inside the image binds its port like any server tmp/ and logs/ via declared grants sqlite in the image, or a declared host need tebako press -r ./myapp -e "bin/rails server"

Figure 1 — The packaged app boots the server from inside the image: code, gems, and assets travel with it; ports bind like any server; writable paths are declared grants.

Sinatra: one file, one command

A Sinatra app is the smallest web payload — a config.ru and a gem list:

$ tebako press -r ./webapp -e "rackup -p 3000 config.ru" -o webapp
$ ./webapp
Puma starting in single mode…
* Listening on http://0.0.0.0:3000

The app code, Sinatra, Puma, and every gem travel inside the payload slice. curl localhost:3000 is serving from the package.

Rails: the same, with the pieces named

Rails is bigger, not different. What travels inside the image: the application code, the bundled gems, and the precompiled assets — assets are files like any other, and mounting them beats expecting the host to have them. What stays outside:

  • The port — the server binds it at run time, like any server.

  • The database — an SQLite file can travel inside the image or live on the host; PostgreSQL and friends are host services, reached over the network exactly as in development.

  • Temporary and log paths — a running Rails app writes to tmp/ and log/. Writable host paths are granted by declaration, which the advanced series covers; for a self-contained package, point both at a path inside the mounted image or at $TMPDIR.

$ tebako press -r ./blog -e "bin/rails server -p 3000" -o blog
$ ./blog
=> Booting Puma…
* Listening on http://0.0.0.0:3000

Press it for every platform your users run — the choices are the ones from the previous post.

What you can do now

You can package a web application — Sinatra in one command, Rails with assets inside and services outside — and serve it from a single file. The last post in this series publishes what you have built.

Note

Continue with part 5 of 5: Publish to your users.