Skip to main content
Most apps are more than one service, and each service expects to find the others at a fixed localhost port. Tesser keeps that arrangement on the box. A dependency is a loopback port declared in the manifest, and Tesser connects that port to the right instance of the other service, wherever it is actually running.
The app keeps its existing API_URL=http://localhost:5001 and nothing in it needs to change.

​
Which instance a dependency reaches

A dependency names a service, not a box. Which box it connects to is decided separately for each of your boxes, in this order:
  1. If the same worktree has its own box for that service (because you ran tesser dev api from it), your web box’s api port connects to that box. Tesser wires sibling boxes from one worktree to each other automatically.
  2. Otherwise it connects to the org’s shared instance of api, which is the pinned copy of main described below.
  3. If neither exists, dev still starts the server and prints a warning that the dependency has nothing behind it.
Shared instances never connect back into anyone’s dev box, so work in progress on one person’s branch cannot affect a teammate.

​
The shared copy of main

A pinned instance runs one service at one specific commit, with no laptop involved. It is what everyone’s boxes use for the services they are not currently working on.
This creates a box, checks out that commit on it, runs setup and dev, waits for the health check to pass, and makes the box the org’s default for api. Running the command again with the same commit does nothing and prints the same box id. Running it with a new commit starts a new box, waits until the new box is healthy, switches the org’s default over, and then removes the old box. To roll back, run it again with the previous commit. Usually CI runs this for each service on every push to main. The box belongs to the org rather than to a person, so it cannot be synced to, and its env values come from tesser env set rather than from a file (see Services). When you start a service whose dependencies are pinned, Tesser wakes or starts those dependencies first.

​
Pointing a dependency somewhere else

The first command points one box’s api dependency at a box you choose, for example a teammate’s box or an older build. --clear returns it to whatever Tesser would choose on its own. The dependency switcher in the panel does the same thing with a click.

​
Tests that need the dependencies

A workbench has no dependencies of its own, because it does not serve anything. For an integration test that expects localhost:5432 to be a database, borrow a service’s dependencies for the run:
The workbench gets api’s dependency ports for as long as the command runs and releases them afterwards. --in api on its own only changes the working directory to api’s root.

​
Names

Service names are shared across the org. api means the same service whether the manifest lives in this repository or another one, which is what lets a dependency declared in one repository reach a service declared in another. Registering a name that another repository already owns is an error.