Editing a running instance
A running GPU instance can have its image, startup command, init script or service port changed in place. EcoLink rebuilds the pod with the new configuration; the instance itself — its id, its GPUs, its volumes, its expiry, its credit hold — stays exactly as it was.
Use it when the image was wrong, when the startup command needs fixing, or when you want to bake what you installed by hand into an init script without losing the machine.
From the console
- Compute → GPU Instances, click the instance.
- Click Edit config.
- Change any of:
| Field | Notes |
|---|---|
| Container image | Cannot be empty. |
| Startup command | Leave empty to keep the container idle so you can SSH in. |
| Init script | Hidden for Jupyter images. Runs before the startup command — see Init scripts. |
| Service port | Empty or 0 closes the public endpoint. |
- Click Save and redeploy.
The button then reads Redeploying… until the new pod is up.
What cannot change
GPU count, GPU type and region. Those mean a new rate, a topped-up or refunded hold, a fresh capacity reservation and — for region — moving volumes that cannot move. That is a different machine, and launching a different machine is what templates are for.
The API refuses them by name rather than ignoring them:
HTTP 400 Bad Request
{ "error": "gpu_count cannot be changed on a running instance — that is a different machine (new rate, new hold, new capacity reservation). Launch one from a template instead." }
What happens during a rebuild
Three things are worth knowing before you click:
- The old pod is deleted before the new one starts. Expect seconds to minutes with no pod — image pull plus init script. EcoLink cannot start the new pod first: it would want the same GPUs the old one is still holding, so it would wait forever and the update would never complete.
- Everything inside the container is lost. Mounted cloud drives and shared filesystems are not affected. This is exactly what init scripts are for — put what you installed by hand into the script and the rebuilt pod installs it for you.
- Billing continues throughout. The GPUs stay reserved for this instance the whole time, so a rebuild is not a pause. Same rate, same hold, same expiry.
The SSH tunnel key is re-minted on every rebuild. If you connect over native SSH, reconnect after the rebuild; the old key stops working.
Rules
| Situation | What happens |
|---|---|
The instance is not running | 409 — instance is pending — only a running instance can be redeployed |
| A rebuild is already in flight | 409 — a redeploy is already in progress — wait for it to finish. Cleared automatically after 15 minutes if something went wrong |
| Nothing actually changed | 200, changed: false, and the instance is left alone. Whitespace-only differences do not count as a change, so a stray space in a textarea will not cost you a rebuild |
| An init script on a Jupyter image | 400 — the image keeps its own entrypoint, so the script would never run |
From the API
curl https://api.ecohash.com/gpu-instances/142 \
-X PATCH \
-H "Authorization: Bearer eco_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{
"container_image": "vllm/vllm-openai:latest",
"startup_command": "",
"init_script": "pip install -r /mnt/models/requirements.txt",
"service_port": 8000
}'
Every field is optional; anything you leave out is left alone. A field sent as "" clears it.
HTTP 202 Accepted
{
"id": 142,
"changed": true,
"note": "Redeploying: the old pod is deleted before the new one starts, so anything inside the container is lost (mounted volumes are not). Billing continues throughout.",
"instance": { "...": "..." }
}
While redeploy_requested_at on the instance is non-null, a rebuild is in flight.