Packaging made simple

Distributing and installing modern web applications is a pain.
We automatically package them so you don't have to.

Push new code to GitHub

Packages get built automatically

Deploy packages on your servers using APT, YUM, ZYPPER

Build and operate your apps the Heroku way, on your own servers

Get Debian, Ubuntu, CentOS/RHEL, and SuSE Linux Enterprise Server packages built on demand, including a powerful CLI to scale, run, inspect, and configure your applications, on your own servers.

Scale your processes up and down:

my-app scale web=1 worker=2

Run arbitrary processes in the context of your application:

my-app run ruby -v
my-app run rake db:migrate
my-app run console

Inspect your application's logs:

my-app logs

Set configuration variables for your application:

my-app config:set DATABASE_URL=...

Start/Stop/Restart the application, in a distribution-independent way:

my-app start|stop|restart [web|worker]

Advantages of a package-based installation

Install and update in one command

It's a fact: modern web applications are a pain to install. With packages, no more complicated install intructions, and no need for heavy-duty configuration management tools to install an app. Packages get built and hosted in your own package repository, so that you (or your clients/users) can just apt-get install (or yum install) the application and be done with it.

Based on Heroku buildpacks

Heroku buildpacks are a standard for web application deployment. That means you're not entering some dark world, but you just use our (slightly) customized version of the Heroku buildpacks you've known and loved for a long time!

Super-Fast

Everything is precompiled, which makes for a really fast installation procedure. On any number of servers.

Self-contained

Packages only embed what's absolutely required to make your app work. This includes the language runtime of your app (Ruby, NodeJS) and its dependencies (gems, modules, etc.). For the rest, packages rely on the system libraries of the distribution as much as possible.

Support for multiple delivery channels

Get packages built for some or all of your branches, so that you can keep maintaining multiple delivery channels of your software in parallel (e.g. staging, production, release/7.1).

Secure package repository

All your packages are published to a package repository dedicated to your application, complete with authentication tokens if you want to restrict access. Plus your repository metadata is signed using GPG, and only available through HTTPS.

Analytics

What if you could know how many times your packages have been downloaded? And from where? And how many servers are still polling for updates? We surface all those informations on a map so that you can see at a glance your installation base.

A few notes from happy users

Prior to using Packager.io we experimented with many options. The obvious starting point was a combination of Chef or Puppet with Capistrano. Chef/Puppet get it to the point where Capistrano can deploy the application, but that still leaves a lot to be desired. It's also not in any way "simple". As a former professional systems administrator, I'm very sympathetic to the needs of the Ops Team. Anything we as developers can do to lighten their load just means better uptime for us.

We've used Packager.io to publish Joola as packages for Debian, Ubuntu and CentOS and we wanted to share our reasoning behind offering Joola as a packaged downloadable and our experience with Packager.io. Spoiler alert: it took us less than 10 minutes, worked on the first time and was overall awesome!

THE LONG STORY

Today, when the time comes to deploy a web application, the choice is either to use a PaaS (over which you have no control), or spend time configuring various tools such as Puppet, Capistrano, Chef, Fabric, Docker (the list goes on) to simplify the process of releasing new code to your own servers.

Some of these tools are excellent for configuring your infrastructure, but are they really needed to handle the nitty gritty details of what essentially amounts to: install those dependencies, copy those files here, start a daemon and ensure it runs smoothly over time?

Wouldn't it be great if you could have a native (DEB or RPM) package that automatically does this for you? Most of the applications present on your servers are installable that way, and I'd bet that you quite liked the feeling of an apt-get install stuff the first time you tried it.

Look at what you no longer have to do!

Create a new (unprivileged) deploy user

install the right version of Ruby (from source, rbenv, rvm, or third-party packages, since your OS most likely does not provide the version you want)

err, I mean, apt-get install a slew of dependencies, then install the right version of Ruby

upload the latest code to the server (bonus points for not leaving sensitive github credentials around)

Step 2: Serve packages from your own APT / YUM / ZYPPER repository

Icing on the cake: every package built for your app will automatically be added to your own APT / YUM / ZYPPER package repository.

This is the final step that allows a seamless delivery to your users, using the tools they use everyday to manage their Linux distribution. A package repository hosts DEB or RPM packages, with a few additional security features such as:

GPG signing of the metatada files

private repository support using access tokens

encrypted file delivery using HTTPS end-to-end

Step 3: Install and relax while your package sets everything for you

Now that your package is built and available from a package repository, you or your clients can just use the distribution's package manager (APT, YUM, ZYPPER) to install it, using the usual commands apt-get install, yum install, or zypper install.

System dependencies get automatically installed.

For interpreted languages, your package ships with your own version of Ruby/NodeJS (the one you specified in your Gemfile or package.json file), so that it does not conflict with any other version you installed system-wide.