Deploy an app

How it goes

Your application is a public project on gitlab.common-lisp.net (project hosting; get an account). Open it in the lab, by its group/project name, and press Deploy; a Maintainer of the project approves it there, signed in with GitLab. The house builds the project's default branch from its own description, runs it in a container with no network, checks it, reads it, and puts it up at your-name.common-lisp.app. What runs is what anyone can read on GitLab, at the commit that went up.

What it takes is in the project itself: a build description and a manifest, the five rules below. Opening a project and deploying it are free. An application that is not there yet can have the lab's agent bring it into the profile, paid in mites from the community pot.

What the application must do

The profile is Monocle's, profile 1: five rules, meant to be met in an afternoon and plain enough for a program to check. The one idea is that the application carries no payment code: it is reachable only through the house's gate, so the gate takes the toll.

1. It builds from a description, not from instructions. image.sexp at the root of the repository, the custom-image spec: the base image, the pinned Quicklisp dist, the systems to load, the Debian packages, and the form that starts the application. Custom images writes one for you, in a form or with the agent. Every dependency is in the pinned dist or in the repository.
2. One command starts it, and it listens on $PORT. Plain HTTP on 0.0.0.0, no TLS and no knowledge of its own host name; logs on standard output; a fatal error ends the process, so that it is started again.
3. GET /healthz answers 200 within a minute of starting, and for as long as the application can serve.
4. It keeps state only under $DATA_DIR. Everything else in the container is thrown away at a restart, and the application may be stopped when idle and started again on a request. Outbound network access is off unless the manifest names the hosts it needs.
5. Tolls are declared, not enforced. monetize.sexp, beside the build description, names the application (its address is made from the name), its licence, and what costs money: each toll a label, a price in mites, and the paths it stands on. A request to a tolled path that is not paid for gets the house's page for paying it, and the application never sees it; a paid one is passed on. / is always free, and so is the health path.

The house's check is a program with no judgement in it: it builds the image from the description, runs it with PORT and DATA_DIR, no network, a memory limit and a read-only root, expects /healthz and / to answer, tries every tolled path, stops it and starts it again, and, for an application under the AGPL, expects / to link its source. A request the review flags waits for an admin.

Licences

The application's licence is yours to choose, within what it uses when it runs. One that uses no Gendl and no other AGPL- or GPL-licensed code goes out under any licence, closed source included, and the house serves nothing of its source. One built on Gendl, or on other AGPL code, is under the AGPL, and its pages link its public repository. How it was written does not enter into it: an application written with the lab's agent is not under the AGPL for that reason.

Not there yet?

Open the project in the lab and ask the agent to bring it into the profile: it works on your files in its session, and the changes go back to GitLab as a branch and a merge request you approve. The agent's work takes mites from the community pot, which anyone may top up; deploying never does.