Getting started

From a folder on your machine to a coworker using it.

You need an app that runs locally, and access to a Spryloom. Release 1 is invite-only, so somebody will have given you an address to point at.

1. Install

npm install -g spryloom

One package, one command. Node 20.19 or newer, which you have if you are running a coding agent.

spry --version

2. Sign in

spry login --email you@yourcompany.com

Your terminal prints a short code and waits. Spryloom emails you a link; open it, check that the page shows the same code, and confirm.

The code matters. A link on its own would approve whichever sign-in it was made for, including one somebody else started — so the page asks you to confirm the sign-in in front of you is yours. If the codes differ, close the page and nothing happens.

There is no password to choose or remember.

3. Publish

From the folder holding your app:

spry publish .

Spryloom reads the folder, builds it, gives it somewhere to run and an address, and waits until it is actually answering before telling you it is live.

Publishing Expense Notes

  ✓ Runtime created
  ✓ Database created
  ✓ Sign-in enabled for yourcompany.com
  ✓ HTTPS enabled

https://expense-notes.yourcompany-com.spryloom.app

  version   1
  built in  6s

If the folder has no spryloom.yaml, Spryloom writes one from what it found and asks you for one thing it cannot work out: a sentence saying what the app does.

spry publish . --description "Tracks expenses that need a second look."

That sentence is not a formality. Your coworkers read it before opening something a colleague made, and it appears in the invitation email and on the app's own page. See the manifest for everything else it declares.

Publishing from somewhere else

The same command takes a zip of the folder, or a GitHub repository:

spry publish ./expense-notes.zip
spry publish github.com/you/expense-notes
spry publish github.com/you/expense-notes@a-branch

Both are read on your machine and become a folder before anything is uploaded, so everything above applies to them unchanged. For a private repository, set GITHUB_TOKEN: it is sent to GitHub to fetch the code and reaches Spryloom at no point.

4. Let somebody use it

spry invite expense-notes --email ryan@yourcompany.com

Ryan gets an email saying who invited him, what the app is, and what it does. He clicks the link, receives a sign-in link of his own, and is in. He never chooses a password, and you never set one up.

If your app is shared with your whole company — see who can use your app — anybody at your domain can open it without being invited at all.

5. Watch what happens

spry apps                      what you have, and whether it is running
spry logs expense-notes        what the app printed

Or open the dashboard in a browser, which shows the same thing plus who has used each app, which versions exist, and anything that needs attention.

Publishing from your coding agent

Everything above, done for you by the agent that wrote the app. Two commands, once per project:

spry skill                    teach the agent in this project how to write apps that publish
claude mcp add spryloom -- spry mcp

The first writes a skill into .claude/skills/spryloom/, which is what makes an app publish on the first attempt rather than the third — the port it listens on, the lockfile, the manifest. The second gives the agent the tools to publish, check on an app, read its logs, roll it back, and invite people.

Then you ask, in the language you would use with a colleague:

Publish this for the finance team.

For Codex and Cursor, point them at spry mcp however they take an MCP server; the tools carry their own instructions, so no skill file is needed.

The agent acts as whoever this terminal is signed in as. spry login first.

Changing it

Publish again. The address stays the same, the data stays where it is, and the version number goes up.

spry publish .

If the new version is wrong:

spry rollback expense-notes

That returns the app to the previous version, which is still there. Your data is untouched — rolling back changes which code is running, nothing else.

Writing an app that publishes cleanly

Most failures are decided before you run publish. Four things matter, and your coding agent should be doing all four for you:

Listen on the port Spryloom gives you. An app that listens on a fixed number builds fine and then serves nothing.

server.listen(process.env.PORT || 3000, '0.0.0.0');

0.0.0.0, not 127.0.0.1. An app bound to loopback cannot be reached from outside itself.

Read settings from the environment, never from a file you committed. Your database URL and your secrets arrive that way.

Commit a lockfile. Without it, the versions built are not the versions you tested.

Keep what matters in the database. Files written next to the code disappear when the app restarts. See data and secrets.

Next