ShoalStack is now
Attach a public or private repository to a container or function on the platform201 visual graph, select a branch, and build from your Dockerfile or a detected stack.
A container or function on the graph holds its own source. Attach a repository, or upload your code, and choose how the build works. Each deployment then reports its status and logs.
Attach a repository to a container or function through the
GitHub App. For a private repository, authorize the app
for specific repositories.
A node listens on the branch you select. A push to that branch starts a new deployment. You can disable this and start each deployment yourself.
Provide a Dockerfile for full control, or let platform201
detect the stack. With no Dockerfile, containers accept
install, build, and run commands.
A folder or a zip also works as a source. platform201 removes dependencies and caches, and a function can start from a template in the editor.
Your code might sit in one repository for each service, in one monorepo for all of them, or not on GitHub at all. platform201 sets the source on each node, so the graph fits how you store code.
Keep the frontend, the API, and the worker in separate repositories. Each node builds from its own.
Add one container or function for each app. On each node, set a different folder to build from.
Select a folder or upload a zip for a container. The files must be at the root of the zip.
As an example, take one web app in a subfolder of a repository, with one container and one gateway. These steps go from a new environment to the live app, and then to a later push.
In platform201, create an environment. The graph already shows a gateway connected to a container, so the web app has the two nodes it needs.
Click GitHub in the source section of the container. Select the repository and the branch. Then set the folder in the repository to build from.
Press Deploy. With no Dockerfile in the source, platform201 detects the stack and builds the web app. When the status shows succeeded, open the gateway URL.
Push a change to the branch the container listens on. A new deployment starts, and its version and status appear in the deployment history.
A service with a source is one node on the graph. Add the nodes around it, deploy them together as one version, and read the status and the log of each version after a push.
Begin with one container behind a gateway, and attach a repository or upload your code. When the app needs more services, add them to the same graph and connect them.
Continuous deployment is a practice in which a push to a branch starts a new deployment without a manual step. Each change then uses the same build steps, and the team does not need to remember to deploy. Teams usually review or test code before they push to that branch. In platform201, a push to the branch a node listens on starts a new deployment, and you can disable this behavior.