CLI reference

saasie app

Work with one Saasie (what it is running, its log, its keys)

Usage: saasie app <name> <group> <action> [options]

Work with one Saasie.

Groups:
  git get-url [--protocol ssh|https] [--with-credentials]
                                       Print the clone URL
  db get-url                           Print the Postgres connection URL
  db info                              Which cluster it is on, and as whom
  analytics types                      The event types the app has registered
  analytics count --type <name> [--since <duration>] [--interval <unit>]
                  [--group-by <property>]
                                       Count events over a range
  mail                                 Its sending address, and what it sent
  status                               What is running right now
  logs [<service>] [--tail <n>] [--since <duration>] [--previous]
                                       A service's log
  build list                           Recent builds, newest first
  build show <number>                  One build, and why it failed
  key add <file> [--title <name>] [--read-only]
                                       Let a public key clone and push
  key list                             The keys that can reach this Saasie
  key remove <id>                      Revoke one

A key reaches this Saasie's repo and nothing else on the platform, so use
one key per Saasie rather than one key everywhere. Pass "-" as <file> to
read the key from standard input.

Over https the credential is your API token rather than a key, which is
what makes cloning work from CI and from sandboxes that only allow port
443. Prefer the credential helper, which keeps the token out of the clone:

  git config --global credential.helper '!saasie git-credential'

--with-credentials puts the token in the URL instead, for somewhere that
cannot run a helper. Git writes that URL into .git/config, so the clone
carries a live token from then on.

status and logs read the cluster, not the control plane's records, and that
is the point: a build reports "live" once the deployer has applied it, which
stays true while the container it started crashes on boot. When the URL
answers 502 and the newest build is green, this is where the answer is.

  saasie app acme status                what is running, and why it is not
  saasie app acme logs                  what it has said lately
  saasie app acme logs --previous       what it said before it died

status names the failing health path too. A container that is up and never
answers its declared path is not sent any traffic, so the URL 502s while
nothing crashes, nothing restarts and the log stays empty — the one failure
that looks like nothing being wrong.

analytics and mail read what the app itself has been doing with its
batteries. They are read-only here: registering an event type, logging an
event and sending a mail are things the app does with its own token, and
doing them by hand would put entries in the record the app never made.

A Saasie sends from one address, which mail shows. Bodies are never kept —
the platform records a recipient and a subject, and nothing else.

Examples:
  git clone "$(saasie app acme git get-url)"
  git clone "$(saasie app acme git get-url --protocol https)"
  saasie app acme key add ~/.ssh/id_ed25519.pub
  psql "$(saasie app acme db get-url)"
  saasie app acme build list
  saasie app acme logs worker --tail 500 --since 15m
  saasie app acme analytics count --type signup --since 30d --group-by plan
  saasie app acme mail

The same text, on your machine: saasie app --help