Deploying an application
From a repository to a running address, and what happens at each step.
An application is one running program with an address. This page covers how it gets there, what you control, and what the platform decides for you.
Where the code comes from
From a connected repository. You authorise ISOGrid against your code host once, choose a repository and a branch, and the platform builds from it. It only ever sees the repositories you select — authorising the connection does not hand over your whole account.
From something already packaged. If your team already produces a deployable artefact, upload it to your organization's private registry and deploy that. Nothing is built; the platform runs what you gave it.
Working out how to build it
Most repositories do not say how they should be built, so the platform works it out: what language and framework it is, how dependencies are installed, what command starts it, and which port it listens on.
Two things worth knowing:
It will ask rather than guess. If a repository is ambiguous — two possible entry points, no obvious start command — you get a question, not a build that half works. Answering once is enough; the answer is remembered for that application.
You can override everything. The detected settings are a starting point, not a verdict. If you know the start command, set it.
If your repository already carries its own build definition, that is used as-is and nothing is detected.
Choosing a size
Sizes are offered as named instance types per region, not as raw numbers you invent. Each names what it costs. The reason for named sizes rather than free choice is that an arbitrary combination cannot be priced honestly or scheduled predictably.
Pick the smallest that holds your application. Moving up later is a restart, not a rebuild.
Copies, and what they mean
One copy is the default and the cheapest. It is also a single point of failure: while it restarts, nobody can reach your application. Fine for a staging environment, not for anything a customer touches.
Two or more copies are placed on different machines where the region has them. Requests are spread across them, and losing one costs you capacity rather than availability.
Copies do not share local disk. Anything written inside a running copy is lost when it restarts and is invisible to the others. If your application writes files it needs to keep, it needs a volume or a store — and if it writes files it needs to share, it needs a store, because a volume belongs to one copy.
Deploying, and what a deployment does not interrupt
A deployment starts the new version, waits for it to answer, moves traffic across, and only then stops the old one. If the new version never answers, the old one stays serving and the deployment is reported as failed. A broken deploy should cost you a red mark in the history, not an outage.
With a single copy this is not possible: there is nowhere to run the new version while the old one serves, so there is a gap of a few seconds. This is the most common surprise on the free and smallest tiers, and the fix is a second copy.
Environment and configuration
Values your application reads from its environment are set per application. Ordinary settings are visible to anyone who can see the application.
Secrets are different. A value stored as a secret is write-only: you set it, the running application receives it, and nobody — including you — can read it back through the console or the API afterwards. This is deliberate. A secret you can retrieve from a web page is a secret that leaves in a screenshot. If you lose it, replace it.
Changing either restarts the application, because a running program reads its environment once at startup.
Edge cases worth knowing before you meet them
The build succeeds and the application still will not start. Almost always a missing environment value or a database that is not reachable yet. The logs from the failing copy say which; they are kept even for copies that never became healthy, precisely for this.
The application starts but nothing reaches it. It is listening on a
different port from the one the platform was told, or on localhost only.
A program bound to localhost inside its own copy is unreachable from
anywhere else by design. Bind to all interfaces.
The application is slow to start and gets killed. The platform waits a generous but finite time for a new copy to answer. An application that needs to run migrations, warm a cache and index something before it answers may exceed it. Do that work in the background and answer immediately, or the deployment will keep rolling back a version that was going to be fine.
A deployment succeeds but traffic still hits the old version. Give it a moment — connections already open are allowed to finish rather than being cut. Long-lived connections are the usual cause; a client holding one will keep talking to the old copy until it reconnects.
Two deployments at once. The second waits for the first. They are not applied in parallel, because two rollouts of the same application racing each other can leave copies of three different versions serving at the same time.