Apps
The repositories that make up one application, with the commands that build and run each part.
- Reading time
- 2 min read
- Who
- Can manage deployments. Reads are gated too, not just writes.
How it works
An App is the set of repositories that make up one application, and it is the unit a person picks. Creating a workspace starts by choosing the App being worked on, and the repos come with it, narrowing to one is optional and worth doing when the work only touches one, because the agent reads what is in the workspace.
It is also the unit a deployment resolves: deploy a frontend and the rest of its App comes up too. A repo belongs to at most one App, by construction.
Each part of an App, a repo, or a directory inside a monorepo, carries its own recipe: the install, build and start commands, a port, what kind of thing it is (frontend, backend, worker), a Dockerfile path or a static output directory, and which secrets it needs. You can write these by hand, or have DevBench read the repo in a throwaway box and propose them; nothing is written until you apply the proposal.
Apps also own databases and their seed SQL, the data a preview boots with. A schema change belongs in a migration rather than in the seed.
Apps has its own place in the top bar, after Home. An App's page has six tabs: Overview (its recent workspaces, its guidelines, what it still needs, its repos and docs at a glance), Workspaces, Docs, Repos & databases, Environments and Settings (guidelines for its agents, its SSH key, rename and delete). A workspace does not have to be on an App: New workspace still makes one from repos alone.
Steps
Click Apps in the top bar, after Home (or the search: Ctrl Ctrl, ⌘ ⌘ on a Mac).
Every App as a card: what it is, its repos, how many workspaces are on it and when they were last active.
Create an App and add the repositories that make it up.
On its page: Repos & databases.
Open an App's Workspaces or Docs tab.
The workspaces made on its repos, and the docs shared with it or written in them. New workspace there starts the usual wizard with the App picked.
Press Configure on a part to set its install, build and start commands, its port and its kind.
A monorepo has one part per directory.
Or press Generate to have DevBench read the repo and propose the recipe.
Review it, then apply, nothing is written until you do.
Add a database and its seed SQL if previews need data to boot with.
The seed editor loads the stored SQL before showing you a box, an empty box saved over a real dump is unrecoverable.
Say where each part deploys.
That is what a deployment resolves against.
Commands
The same job from a workspace's box, for people who live in the terminal.
$ devbench deploy config set <repo>[/<dir>] --start … --build …Create or edit one part's recipe.$ devbench deploy databasesThe deploy databases for this workspace.$ devbench deploy seed showPrint a deploy database's seed SQL.$ devbench deploy seed set --file <path>Replace the seed. For schema changes, add a migration instead.