Skip to content

Deployment and CI/CD Updated 2026-05-27

Container redeploy

How container redeployment works on Stack Harbor PaaS — switching a container to a new image tag while preserving custom configuration, volumes, and stack-specific files.

Container redeploy is the operation that switches a running container to a different image tag. The container is rebuilt from the new image while the platform automatically preserves custom configuration, volume contents, and stack-specific files.

Redeploy is the way you apply image-level updates to a container: a new minor version of the application server, a patched base OS image, a custom image with additional packages baked in. It is distinct from application deployment, which only updates the code running on top of the container.

When to redeploy

  • Pick up a security patch in the base image.
  • Move from one stack version to a newer one (for example, Tomcat 9 to Tomcat 10).
  • Switch to a custom container image you built and pushed to your registry.

For code-only changes, use application deployment (archive, VCS, or Git-Push-Deploy). Redeploy is unnecessary and slower.

How redeploy works

Three steps run under the hood:

  1. The platform records the data that needs to survive — volumes, custom files listed in /etc/jelastic/redeploy.conf, and certain platform-managed system files (SSH keys, firewall rules, AutoFS / NFS configuration).
  2. The container is rebuilt from the new image tag. The original container filesystem is replaced.
  3. The preserved data is restored into the new container filesystem.

The container ends up running the new image with your application configuration intact.

Triggering a redeploy

Three driver surfaces:

  • Dashboard — hover over a container in the environment view and click Redeploy. Pick the new image tag from the dialog.
  • CLI — ~/jelastic/environment/control/redeploycontainerbyid or ~/jelastic/environment/control/redeploycontainersbygroup cover single-container and layer-level redeploys.
  • API — the same operations are accessible via REST API calls.

Cloud Scripting manifests can also trigger redeploy as part of a larger workflow.

What gets preserved

The platform preserves three categories of data automatically:

  • Volumes — both default and custom volumes attached to the container. Their contents survive intact.
  • Custom container configuration — run commands, links between containers, environment variables, port mappings.
  • System files — SSH access (/root/.ssh/authorized_keys and related), firewall rules, AutoFS / NFS configuration, and the stack-specific list maintained in /etc/jelastic/redeploy.conf.

For the full list of preserved system files per stack — and the mechanism for adding your own custom files to the preservation list — see redeploy preserved data.

What gets reset

Anything outside the preserved list is reset to the state baked into the new image:

  • Application server configuration files that ship with the stack.
  • Application code in stack-default paths (unless the path is volume-backed).
  • Custom packages installed inside the container via apt/yum/etc. (unless captured by a deploy hook or baked into a custom image).
  • Log files written to non-volume paths.

If you maintain custom configuration outside the preserved list, add the file paths to the custom files and folders section of /etc/jelastic/redeploy.conf before redeploying.

Sequential redeploy for scaled layers

For application server layers scaled to multiple instances, redeploy is applied one instance at a time with a default 30-second delay. The remaining instances continue serving traffic during the rollout. This is automatic and requires no configuration beyond having the scaled layer.

For a smaller delay or no delay, adjust via the CLI flags on the redeploy call.

Failure handling

If the new image fails to start, the container is left in an error state. The platform does not automatically roll back. Options:

  • Inspect the container logs to identify the failure (typically a missing config file or an incompatible runtime setting).
  • Redeploy again to a known-good tag.
  • For scaled layers, the failed instance is taken out of rotation; healthy instances continue to serve traffic until you complete the rollback.

See also