ShoalStack is now
ShoalStack is now
Place your services and their connections on a visual platform201 graph, then deploy the whole environment in one step, without manual setup in a cloud console.
A deployment takes the current version of the visual graph that describes your environment.
It creates or updates each service, applies the connections and routes, and builds each from source.
Edit the graph, then deploy. platform201 sends the current version in the background and tracks it from pending to succeeded or failed.
A connected database gives its connection values to the
variable names you set. The same deployment creates the
gateway routes for your services.
Attach an uploaded archive or a GitHub source to a container.
Set its language, root directory, and build commands, or include
your own Dockerfile.
Change a setting, source, variable, or route, and save the graph.
Then deploy again. The deployment history shows each version
as a new entry.
Whether you ship several new services, change one running service, or recover from a failed version, you edit the graph, save it, and deploy the environment again.
Save a gateway, a frontend, an API, a queue, a worker, and a database.
Deploy them as one version.
Change its source or settings on the graph. Then deploy the environment again as a new version.
Read the log of the failed version.
Correct the graph, source, or settings,
and deploy again.
Suppose an API container with a database and a gateway already runs in platform201.
You change the memory of the API, add a worker, and deploy both changes as one new version.
In the platform201 graph editor, change the memory of the API container. Add a container node for the new worker, with its language, port, and source.
Connect the existing gateway to the new worker on a path such as /worker. Its public address is the full gateway URL, followed by that path.
Save the graph. The new version holds the memory change, the worker, and its route. platform201 deploys nothing until you start the next deployment.
Start the deployment. Follow its new entry in the deployment history until it reaches succeeded. If it fails, open its log to find the exact cause.
A deployment starts with a graph and ends with a status and a log. You can build the graph faster from a Blueprint, and you can check each version after it runs.
Add a container with its source, language, and port. Route it through a gateway and deploy. Later changes use the same steps: edit the graph, save it, and deploy the environment again.
A deployment version is a numbered snapshot of the configuration that a deployment applied. Because each deployment has its own version, you can tell which configuration runs now and which one ran before a change. In platform201, each deployment of an environment gets a version number in the deployment history.
