Your app's manifest

spryloom.yaml sits in your app's folder and says what the app is. Spryloom builds exactly what it declares.

It is a contract, not configuration. It lives in your repository, you can read and edit it by hand, and it is what your coworkers are shown — the description appears in their invitation email, and what the app stores appears on its page. Nothing about your app is inferred behind your back.

Your coding agent writes it while it builds the app. spry init writes one too, and spry publish writes one if there is none.

The whole thing

app:
  name: Expense Notes
  slug: expense-notes
  description: Tracks expenses that need a second look.

runtime:
  frontend: none
  backend: node
  start: node server.mjs

access:
  visibility: company
  domain: yourcompany.com
  signin: [email_link]
  admins: [priya@yourcompany.com]

data:
  postgres: true
  tables: [expenses, approvals]
  uploads: false

app

Field
name What people call it. Shown everywhere a person sees the app.
slug The first part of its address, and what commands take. Lower case, letters, digits and hyphens. Derived from the name if you leave it out.
description One sentence saying what the app does for the person using it. Required.

The description is the one field worth thinking about. Your coworkers read it before opening something a colleague made, and "internal tool" tells them nothing. Write what it does for them.

runtime

Field
frontend none, static, or react.
backend none or node.
start The command that starts the app. Required unless you supply a Dockerfile.
build A build command, when the app needs one. Optional.
dockerfile Path to your own Dockerfile. Optional — see below.

frontend and backend cannot both be none: there would be nothing to run.

Python is named in the plan and is not built. Today this is Node, with a static or React front end.

You do not need a Dockerfile. Spryloom writes one, correctly, from what is here. If your app already has one it is used exactly as it is, and nothing is overwritten.

access

Field
visibility private, invited, company, or link.
domain Email domain. Required when visibility is company.
signin How people sign in. [email_link] today.
admins Email addresses that get the admin role. Optional.

See who can use your app for what each of those means and how your app is told which role somebody has.

signin also accepts google, which does nothing yet — do not declare it. The app's page tells your coworkers how they will actually sign in, and naming a method that is not there would make that page wrong.

data

Field
postgres true gives the app a database of its own.
tables What the app keeps in it. Shown to your coworkers.
uploads false. File uploads are Release 2.

tables is what you tell people, not what Spryloom creates — your app creates its own tables. See data and secrets.

jobs and egress

Both are accepted and both do nothing today.

  • jobs — work on a schedule. Release 2.
  • egress — hosts the app may reach. Declaring one is refused rather than ignored, because an app allowed to reach something it cannot reach would be a worse answer than being told.

Editing it

Change it and publish again. Everything in it takes effect on the next publish: who can use the app, what it is called, what it declares that it stores.

Two things are worth knowing:

  • Changing the slug makes a new app, at a new address, with its own database. It does not rename the old one.
  • Removing postgres: true does not delete the database. The app stops being given a connection string; the data stays where it is.