ShoalStack is now
ShoalStack is now
platform201 records each deployment of your backend services with its status and its build log, so you can follow every version and trace the cause of each failure.
platform201 keeps the deployment history, the build logs, and the graph of each environment together. The log of a failed version and the settings behind it are in one place.
Watch each deployment move through pending, prebuilding, building, deploying, and configuring, until the deployment succeeds or fails.
Open the log of a deployment to see its newest lines first.
platform201 collapses repeated lines. Page back for earlier
output on long builds.
The graph shows each container, function, database, queue, gateway, scheduler, and VM in the environment, and the connections between them.
Select a node to check its region, port, source, routes,
schedule, or machine type, along with the names of the
variables it receives.
Some questions start with a failed build. Others start with a service that has errors after a release, or with an environment that a teammate built. The answers are in the same environment.
See the failed status on the version, and read the deployment output that shows where it stopped.
Compare the gateway routes and the settings of each service with the latest deployment and its log.
Read the nodes, routes, and connections on the graph before you change anything a teammate built.
Here, the latest platform201 deployment of an API failed during the build. The steps go from the failed version to its log, and then back to the graph to fix the cause and deploy again.
In platform201, open the environment and its deployment history. The history lists each version by number, with a status such as building or failed.
Select the version with the failed status to open its details. There you can read the deployment output that platform201 recorded for that run.
Read the newest log lines to find the build or configuration step that failed. Page back through earlier output whenever you need more context.
Correct the source, variable, or connection on the graph, and then deploy again. The new version appears in the history and moves through each of its statuses.
What you can check after a deployment depends on what you put on the graph. These capabilities shape the versions, logs, and node settings you check after each deployment.
Put one container behind a gateway, and follow its first deployment to succeeded. When you add databases, queues, and schedulers, the deployment history and the logs cover them too.
A deployment usually waits in a queue, builds a container image from the source, starts the new version, and then applies routes and settings. The status tells you which stage is running, so a failure points to one stage. A platform201 deployment moves through pending, prebuilding, building, deploying, and configuring, and it ends as succeeded or failed.
