When something goes wrong

Use this page when you see an error on the screen. Find the message you see in the table. Then do what its entry says.

How to use this page

This section tells you how to find help for your error in three steps.

  1. Find the message you see in the table of messages. The panel’s sentence is in the first column, word for word.

  2. Click the link in the last column. It opens the entry for that message.

  3. Do the steps in What to do, in order.

If your message is not in the table, see An install failed with no reason named. Then open a ticket with the files listed in What to attach to a ticket.

You can also ask the AI assistant about your error. See Ask the AI assistant.

For what the tool does, see Deployment Manager. For the deploy panel itself, see Step 6. Deploy.

Who fixes it: three zones

Every entry belongs to one of three zones. The zone tells you who fixes the problem.

Zone Meaning

Deployment Manager (in the table: DM)

The tool refused, or got something wrong. Usually nothing on the customer’s server was changed. There is nothing to undo. We fix it. Report it.

The software being installed, or its configuration (in the table: Installed software)

The bundle reached the server and the installer ran. But the installed software did not start. Or it started and then refused work. Send it to the team that owns that service.

The server or the site around it (in the table: Server/site)

The problem is the machine itself, its network, or something else already running on it. It is not the tool and not the installed software.

Messages the panel shows

This table lists the messages you will meet most often. Find yours, then open its entry. A line in brackets has no panel message. It describes what you see instead. The panel has a few more messages than this table. If yours is not here, read the transcript line just above it, then see What to attach to a ticket.

Panel says Zone Full entry

"the server readiness checks did not pass"

DM

"the server readiness checks did not pass"

"a command required to deploy was not available"

Server/site

"a command required to deploy was not available"

(readiness check listen_ports failed: a port is already in use)

Server/site

A port is already in use

(readiness check dns failed: a name does not resolve)

Server/site

A name does not resolve

(readiness check ulimits failed: the limits are too low)

Server/site

The limits on the server are too low

"the deploy stopped while running a server-side step"

DM

"the deploy stopped while running a server-side step"

"the install is not in that directory"

DM

"the install is not in that directory"

"the install environment file is missing from that directory"

DM

"the install environment file is missing from that directory"

"the bundle contains more than one server and none was selected"

DM

"the bundle contains more than one server and none was selected"

(a config file could not be mounted)

Installed software

A config file could not be mounted

"a container did not come up — check its logs"

Installed software

"a container did not come up — check its logs"

(a container restarts with no errors in its log)

Installed software

A container is restarting, and its log has no errors in it

(the database refuses every service’s password)

Installed software

The database refuses the passwords

"the services did not report healthy in time"

Installed software

"the services did not report healthy in time"

(a service is healthy but rejects real clients)

Installed software

A service reports healthy before it accepts real clients

(a stack trace names the wrong layer)

Installed software

A stack trace names something far from the actual cause

"a required secret was missing"

DM

"a required secret was missing"

"the server refused the stored credentials"

Server/site

"the server refused the stored credentials"

"the container images could not be loaded"

Server/site

"the container images could not be loaded"

"the earlier .env could not be put back — check it on the server"

DM

"the earlier .env could not be put back — check it on the server" / "there was no earlier .env on this server to go back to"

"there was no earlier .env on this server to go back to"

DM

"the earlier .env could not be put back — check it on the server" / "there was no earlier .env on this server to go back to"

"the Deployment Manager host ran out of disk space"

DM

"the Deployment Manager host ran out of disk space"

(no reason could be named at all)

DM

An install failed with no reason named

Cases that look like something else

These cases are often misread at first. Read the right column before you act.

It looks like… …but it is actually

A readiness check refuses, and you think something must be rolled back.

No container was touched. The checks run before any container starts or stops. Fix what the check named and press Deploy again.

A container keeps restarting, and its log has no errors.

Not a crash. Docker restarts a container when its main process ends, even with exit code 0.

A redeploy typed new database passwords, and now every service fails to log in.

The database kept its old passwords. deploy.sh prints a warning about this. Use the passwords the database already has.

A service reports healthy, but clients still cannot use it.

Healthy is not the same as ready for traffic.

A container’s first write fails with a permission error that names a file.

The mount is the problem, not the file. Docker creates a missing mount source as root:root.

A stack trace names something that seems unrelated.

It usually is unrelated. Read what the service could not connect to.

Refused before anything was installed

These failures happen before any container starts or stops. The bundle’s files may already be copied to the server, but no running service was changed.

"the server readiness checks did not pass"

What you see. The panel says "the server readiness checks did not pass". Each failing check prints its own name: ulimits, dns, listen_ports or reachable.

What it means. The readiness checks refused before any container was started or stopped. The bundle’s files were already copied into the install directory, but no running service was changed. The same sentence also appears when an upgrade cannot write the server’s .env. Then no check is named. The transcript line says which file, and what to do.

What to do.

  1. Read the line of the check that failed. Do not stop at the panel sentence.

  2. Fix what the check named.

  3. Press Deploy again.

What not to do. Do not look for something to revert or roll back. No container was changed.

Who to ask. Nobody. You fix it yourself. If you open a ticket, attach the preflight transcript and the name of the failed check. Zone: Deployment Manager.

"a command required to deploy was not available"

What you see. The panel says "a command required to deploy was not available". The transcript names the command.

What it means. The installer needs a command that is not on that machine. In local mode the check covers docker. In bootstrap mode it covers ssh and scp.

What to do.

  1. Read which command the transcript names.

  2. Install that command on the server.

  3. Run the install again.

What not to do. Do not assume it is Docker. Two of the three commands it checks are not Docker.

Who to ask. Nobody. You fix it yourself. Keep the transcript line that names the command. Zone: the server or the site around it.

A port is already in use

What you see. The panel says "the server readiness checks did not pass". The listen_ports check line names the port and what holds it.

What it means. The installation needs a port. Something else on that server already uses it.

What to do.

  1. Read the port and what the check names.

  2. If a program that is not a container holds the port, the panel shows Fix it. Press it only if that program may be stopped. It stops that process. It sends SIGTERM first, and SIGKILL only after a wait. You must confirm first.

  3. If another installation’s container holds the port, there is no Fix it. The check names that container. Agree the next step with its owner, or give this installation another port and generate the bundle again.

What not to do. Do not look for this when the port is held by this installation’s own container. That case is not a failure: the check passes, and the deploy replaces the container.

Who to ask. The owner of the program or container that holds the port. Zone: the server or the site around it.

A name does not resolve

What you see. The panel says "the server readiness checks did not pass". The dns check line names the host.

What it means. The server could not find the address for that host name.

What to do.

  1. Read the host name the preflight named.

  2. Fix it in the customer’s DNS, or in /etc/hosts on the server.

What not to do. Do not assume that a name which works on the host also works inside a container. Often it does not. The host’s /etc/hosts is not the container’s.

Who to ask. Nobody, if you control DNS or /etc/hosts on that server. Otherwise, send a request to whoever does. Zone: the server or the site around it.

The limits on the server are too low

What you see. The panel says "the server readiness checks did not pass". The ulimits check line names the limit. The panel shows Fix it.

What it means. The open-file or process limits on that server are lower than the services need.

What to do.

  1. Press Fix it. It writes the limits file.

  2. It can also merge Docker’s daemon.json and restart the Docker daemon. Accept this only if a restart is acceptable. It restarts every container on that host, also ones this tool never installed.

  3. If the host runs anything else, agree the restart with its owners first.

What not to do. Do not set only the * wildcard in limits.conf. The wildcard does not cover root. A deploy often connects as root. This is the "I applied the fix and it did not help" case.

Who to ask. Nobody, you fix it yourself. Note whether you accepted the fix. Note whether other containers on that host had to survive a restart. Zone: the server or the site around it.

The install started, then stopped partway

These failures happen after the install started on the server.

"the deploy stopped while running a server-side step"

What you see. The panel says "the deploy stopped while running a server-side step". The panel marks one step as failed.

What it means. The script stopped inside a server-side step. It could not name a more exact reason. This message is a fallback, not a diagnosis.

What to do.

  1. Open the transcript at the step the panel marks as failed.

  2. Find the command that failed. It is printed there with its exit code.

  3. If that command belongs to the installed software, see "a container did not come up — check its logs".

What not to do. Do not treat this sentence as the diagnosis. It means there is no diagnosis.

Who to ask. The team that owns the service, if the failed command is in its software. If it is unclear, report it with the full transcript around the marked step. Zone: Deployment Manager.

"the install is not in that directory"

What you see. The panel says "the install is not in that directory".

What it means. There is no installation in the directory the deploy was told to use.

What to do.

  1. Check where this installation really is on the server.

  2. The directory is not always the default /usr/local/ft-system. An operator may have typed another one.

  3. Deploy again with the right directory.

What not to do. Do not assume the default directory.

Who to ask. Nobody, you fix it yourself. Note the directory the deploy used and the one the installation uses. Zone: Deployment Manager.

"the install environment file is missing from that directory"

What you see. The panel says "the install environment file is missing from that directory".

What it means. The directory holds an installation, but its .env is missing. Usually a copy stopped partway.

What to do.

  1. Deploy again from the panel.

What not to do. Do not fix the directory by hand and re-run in place. The retry refuses a half-copied install on purpose. Running the installer on a partial bundle makes things worse.

Who to ask. Nobody, you fix it yourself. Zone: Deployment Manager.

"the bundle contains more than one server and none was selected"

What you see. The panel says "the bundle contains more than one server and none was selected".

What it means. The bundle covers more than one server. The script was not told which server it runs on. In a terminal it would ask. From the panel, or when piped, it cannot ask.

What to do.

  1. Run the script with --server-id <id>.

  2. Or run it from the server directory that has the matching server-id file.

What not to do. Do not run it again without naming the server.

Who to ask. Nobody, you fix it yourself. Zone: Deployment Manager.

A container will not come up, or looks wrong

These failures come from the containers after the installer started them.

"a container did not come up — check its logs"

What you see. The panel says "a container did not come up — check its logs". Compose may also print dependency failed to start: container X is unhealthy.

What it means. A container did not come up. It exited, or it runs but its health probe never passed.

What to do.

  1. Read the health probe of the broken container. The transcript prints it.

  2. Run docker logs <container> on that server.

What not to do. Do not trust the dependency line from compose. It always names the container that was waiting. It never names the one that broke.

Who to ask. First find the container that really broke. Then send it to the team that owns the service. Send its logs and health-probe output. Zone: the software being installed.

A container is restarting, and its log has no errors in it

What you see. There is no panel message. The service row shows restarting. The log shows no errors.

What it means. It is not a crash. Docker restarts a container when its main process ends. This happens even with exit code 0. Usually a process moved itself to the background. The main process then had nothing to do and ended.

What to do.

  1. Compare the command:/entrypoint with what the image expects to run in the foreground.

  2. Run docker inspect to see the restart count and the exit code.

What not to do. Do not search the log for an error. A clean exit does not log one.

Who to ask. The team that owns the service. Send the docker inspect output and the image’s own entrypoint and command. Zone: the software being installed.

A config file could not be mounted

What you see. The panel has no sentence of its own for this. On a deploy you see "a container did not come up — check its logs". After you collect diagnostics, Test install says the service could not start because a configuration file it mounts is missing. The container’s log names a file it could not write. It does not name the missing mount. Docker records the real error in State.Error. The container probe does not print that field.

What it means. A file or folder that the container mounts is not where the compose file expects it. Docker creates a missing mount source as root:root. Every application image here runs as a non-root user. So the container’s first write fails with a permission error.

What to do.

  1. Check the paths under the install directory on that server.

  2. Check the owner and permissions of the path the container tried to write to.

What not to do. Do not trust the container’s own message to name the mount.

Who to ask. Nobody, if the missing path is under the install directory. Open a ticket if the contract expects a path that nothing creates. Zone: the software being installed.

"the services did not report healthy in time"

What you see. The panel says "the services did not report healthy in time". The waiting step shows a count that stopped rising.

What it means. Not all services reported healthy before the deadline.

What to do.

  1. Run docker compose ps on that server.

  2. Read the health probe of the container that is not ready.

What not to do. Do not assume "the wait was too short". A run that failed as soon as the wait started never checked anything. That case has a different message ("the deploy stopped while running a server-side step").

Who to ask. The team that owns the service that is not ready. Send the docker compose ps output and the container’s health-probe history. Zone: the software being installed.

A service reports healthy before it accepts real clients

What you see. There is no panel message. The service shows healthy, but clients cannot use it.

What it means. A health endpoint that answers is not the same as a service ready for traffic. Anything that waits only on that endpoint starts too early.

What to do.

  1. Check what the healthcheck probes. It should probe readiness, not only liveness.

What not to do. Do not expect a fix at install time to correct it. The gap is in what the healthcheck measures.

Who to ask. Open a ticket for the team that owns the service. Zone: the software being installed.

A stack trace names something far from the actual cause

What you see. There is no panel message. A stack trace names a part that seems unrelated.

What it means. A service that cannot reach another service often fails several layers away from the real problem.

What to do.

  1. Find what the service could not connect to.

What not to do. Do not read only the class name printed at the top of the trace.

Who to ask. The team that owns the service. Name the connection target, not the top line. Zone: the software being installed.

The database refuses everything after a redeploy

This section covers a database that refuses all services after a redeploy.

The database refuses the passwords

What you see. The panel has no sentence of its own for this. On a deploy you see "a container did not come up — check its logs" or "the services did not report healthy in time". The database starts without errors, then refuses every service: ERROR 1045 (28000): Access denied for user 'ftacs'. You may also see Unknown database 'configs' for a schema whose CREATE never ran.

What it means. The database creates accounts and schemas on its first start only. A redeploy over a data directory that is not empty keeps the old passwords.

What to do.

  1. Find the warning deploy.sh prints before up -d. It starts with the service name and says "already holds data from an earlier install here". It appears once for each database that already has data.

  2. Check whether the data directory was empty before this run.

  3. Use the passwords that the database already has.

What not to do. Do not expect a new .env to change the passwords of an existing database. It does not. Every service fails at once, so it looks like a broken database. This is the most misleading case on this page.

Who to ask. Nobody, you fix it yourself. Use the credentials the database was first created with. Zone: the software being installed.

Credentials and secrets

This section covers missing secrets and refused SSH credentials.

"a required secret was missing"

What you see. The panel says "a required secret was missing".

What it means. A secret the installation needs had no value. A secret is a password, key or token.

What to do.

  1. Enter the value.

  2. Deploy again.

What not to do. Do not worry about a value marked optional that you left empty. It never causes this message.

Who to ask. Nobody, you fix it yourself. See Step 3. Fill in the variables for why a secret is generated, offered, or must be typed. Zone: Deployment Manager.

"the server refused the stored credentials"

What you see. The panel says "the server refused the stored credentials". It offers to add SSH access.

What it means. The server refused the SSH login this tool stores for it.

What to do.

  1. Open Add SSH access on that installation. The deploy panel offers it on this failure.

  2. Store a credential the server accepts.

  3. Deploy again.

What not to do. Do not confuse this with credentials that were never entered. That case has a different screen and a different sentence.

Who to ask. Nobody, you fix it yourself. Zone: the server or the site around it.

Images and the registry

This section covers container images that did not reach the server.

"the container images could not be loaded"

What you see. The panel says "the container images could not be loaded". The transcript says why.

What it means. The container images are not on that machine. Either the server cannot reach the registry, or an offline archive did not load.

What to do.

  1. For a site with no registry access, use the offline archive. Choose Download, then the archive with the images inside it. See Step 4. Create the bundle.

  2. For a site with registry access, check that the server is signed in to the registry (docker login on that server). This tool does not send its own Harbor credentials to a customer’s server.

  3. Check that the server can reach the registry. The SSH access panel on the installation card lists the registry hosts and ports. See What the firewall has to allow, in both directions.

What not to do. Do not guess the cause. Read the transcript first.

Who to ask. Nobody, you fix it yourself. Zone: the server or the site around it.

Rollback of the environment file

This section covers the two sentences about putting back an earlier .env.

"the earlier .env could not be put back — check it on the server" / "there was no earlier .env on this server to go back to"

What you see. One of these two sentences.

What it means.

  • The first sentence: a rollback already reached the server. You must check it by hand.

  • The second sentence: a refusal with nothing touched. There was no earlier .env to restore.

What to do.

  1. For the first sentence, check .env and .env.previous in the install directory on that server. Do this before you deploy again.

  2. For the second sentence, there is nothing to undo. If the current .env is wrong, edit it or deploy again.

What not to do. Do not treat the second sentence as a failure that changed something. It changed nothing.

Who to ask. Nobody, you fix it yourself. Zone: Deployment Manager.

Deployment Manager’s own disk

This section covers a full disk on the Deployment Manager machine.

"the Deployment Manager host ran out of disk space"

What you see. The panel says "the Deployment Manager host ran out of disk space".

What it means. A disk filled up on the machine that runs Deployment Manager. It is not the customer’s disk. A full disk on the customer’s server does not show this message. It shows as a failure with no reason named.

What to do.

  1. Free space on the machine that runs Deployment Manager. The space is used by generated bundle folders and the offline-image-bundle store.

What not to do. Do not clean the customer’s server for this message.

Who to ask. Whoever runs the Deployment Manager host. Zone: Deployment Manager.

No reason could be named at all

This section covers a failure the tool could not classify.

An install failed with no reason named

What you see. The panel says it could not name a reason. It does not guess one.

What it means. This is the one case where the tool really does not know.

What to do.

  1. Collect diagnostics (see Step 7. Check that it works).

  2. Open a ticket. Attach the files in What to attach to a ticket.

What not to do. Do not guess a cause and act on it.

Who to ask. Always open a ticket for this one. Zone: Deployment Manager.

Test install (the sandbox) — a distinct set of reasons

This section covers Test install failures. Test install runs the installer on temporary servers. This tool creates and removes those servers. They are never a customer’s machine. A failure here is about the sandbox. It never means an installation is broken. See Step 5. Test the bundle for what Test install is.

What happened What to do

The temporary servers were being created, and the run gave up partway.

Read the checklist on step 2. It names the step that stopped and what survived. Use it to choose: start again, or retry only the staging step. Do not delete the installation. A test install changes nothing about the installation itself.

The test-install service refused the request before it created anything. Usually every test slot is taken.

Open the occupancy list in the Installations header. It shows who holds the slots. Start again when one is free. Nothing of yours was touched, and no bundle was sent anywhere.

The connection that carried the start ended before a verdict arrived. The temporary servers may be up, or may not be.

Reopen the installation’s Test install screen. It shows what is really running. Do not start a second run first. A lost run holds a slot that nobody can find.

Somebody asked for the lab to be removed, and it was not.

Check the occupancy list. If the run is still listed, ask whoever runs the test-install service to clear it. A record that is free to reuse does not mean the servers stopped.

Traps that are not failure codes

This section covers confusing problems that show no panel message. The panel cannot detect them. Each one has already cost a real deploy.

One service without a start-order group stops the whole compose project

What you see. service "X" depends on undefined service "Y": invalid compose project. It is not only about X. up, ps and even config fail for the whole file. Nothing on that server starts, and nothing can be listed.

What it means. A deploy can be split into waves. Each service then has a group for its wave. A service without a group may depend on a service with a group. Docker Compose then treats that dependency as missing.

What to do.

  1. Report it with the transcript. This is a fault in how the bundle was built.

What not to do. Do not change anything on the customer’s server.

Who to ask. Open a ticket. Zone: the software being installed, or its configuration.

A container restarts forever, exits 0, and its log has no errors

What you see. A container in restarting, with exit code 0. In the diagnostics capture, the "errors in the whole log" section is empty.

What it means. Exit 0 means the process ended normally. Usually a setting never arrived. The image then uses a default that moves its application to the background. The main process has nothing left to wait for, so it ends. Docker restarts it again and again.

A server’s configuration is not one file. There is one shared file per server, plus one file per service. A value in the wrong file reaches no service. It still looks present in the bundle.

What to do.

  1. Check whether the setting arrived. Look in the shared environment file and in the service’s own file.

  2. Read the container’s log for a line that says it started in the background.

  3. Look for a stack trace in a file inside the container. It is not in the diagnostics capture.

What not to do. Do not read "no errors in the log" as "the application is fine".

Who to ask. Open a ticket. Zone: Deployment Manager (a value that reached no file). It looks like a problem in the installed software.

A port that is published is not the port a service is reached on

What you see. There is no message. There are three different port problems.

  • A consumer’s port is not the published one. Services on one server reach each other over the container network. They use the port the service listens on. They do not use the port published to the host. If you change the published port, the consumers do not follow.

  • Two services can want the same host port. A monitoring component and an application component use the same port number by default. The topology refuses this when you save it. It names the port and both services. No shipped topology has this collision. If you see it, somebody must decide which service moves.

  • A readiness check can pass a port that somebody else holds. An older check said only "The port is held by Docker". That was true only for a re-install of this installation. The check now names the container that holds the port. It refuses if the container is not ours. It offers no button to stop it. This tool does not stop somebody else’s service.

Who to ask. It depends on the case. Zone: mixed.

The open-file limit was raised and nothing changed

What you see. You raised the limit, and the deploy still fails the same way.

What it means. The wildcard entry in a limits file does not cover the root account. A deploy often connects as root. So a wildcard-only fix changes nothing for the install.

What to do.

  1. Set the limit for the account the deploy connects as.

  2. The repair can also change the container daemon’s own configuration. Restarting the daemon restarts every container on the machine. This includes containers this tool never installed.

What not to do. Do not treat the daemon restart as a small fix on a shared host.

Who to ask. The owners of the other containers, before a daemon restart. Zone: the server or the site around it.

Database accounts, and the credentials that are not ours to choose

This section adds to the first-boot rule. Three facts about accounts cause login failures that look like broken databases:

  • The service that creates an account owns its password. Another service may need the same credential under a different name. That credential is mapped to it. Do not ask for it again.

  • Some accounts are created by an application’s own migrations, with a fixed value. Nothing the wizard asks can change that password. So the row offers Use shipped value, not Generate. A generated value gives an install that cannot log in. See the three ways a secret is answered.

  • A length limit can make a generated password fatal and permanent. Oracle refuses a value longer than thirty characters with ORA-00972: identifier is too long. A generated password was longer. Then:

    • Its admin account never got its new password.

    • Its setup stopped before the account chain ran.

    • The next restart saw a data directory that was not empty. It skipped setup forever.

      The field now refuses a longer value at once. But a site set up before that change keeps the fault. To set it up cleanly, remove its data directory.

A timezone can also make a database refuse every connection. The driver sends a timezone by region name. The database does not know that region. On Oracle you see ORA-01882: timezone region not found, usually inside ORA-00604: error occurred at recursive SQL level 1. It looks like a password failure, but it is not. The fix is in the service: send an offset, not a region name.

A real password failure reads ORA-01017: invalid username/password on Oracle. On MySQL it reads ERROR 1045 (28000): Access denied for user. For both, check the first-boot rule above first.

Who to ask. The team that owns the service. Zone: the software being installed.

A setting has a second home, and the mounted file wins

What you see. You correct a setting and deploy again. The failure comes back byte-identical.

What it means. Several services start with a configuration file mounted into the container. A setting can be in that file and also in an environment value. Then the mounted file decides. The environment value works only when the file does not set it.

What to do.

  1. Look for the same setting in the configuration file mounted for that service.

  2. On a live host, the repair is often to delete that line from the file.

What not to do. Do not look only in the environment values.

Two real results of this:

  • A cluster address on a single-server install breaks it. The service tells its peers to use a public address, but there are no peers. A client in the same container network goes out to the public address. The connection loops back and times out. A dependent service fails far away. The field is now offered only when more than one member is planned.

  • A name that works on the server may not work inside a container. An entry in the server’s hosts file does not reach a container that looks up names itself.

Who to ask. The team that owns the service. Zone: the software being installed.

A mount that lands on nothing, and a first write that is refused

What you see. One container never becomes healthy. The containers next to it are fine.

What it means. There are two mount faults:

  • Docker creates a missing mount source as root. None of these images run as root. So the first write fails. The error names the file, not the missing folder. The installer now creates every logs and data mount source first, so this is rarer.

  • A mount can point to configuration the bundle does not carry. Docker creates an empty folder there. The service fails on a file it cannot load. Bundle generation now checks every mount. It refuses and names every gap.

What to do.

  1. If you see the second fault while the service runs, report it. It should have been refused before anything was sent.

Who to ask. Open a ticket. Zone: the software being installed, or its configuration.

JVM flags set in the compose file that never reach the JVM

What you see. JVM flags you set have no effect.

What it means. The variable long used for JVM flags is not read by the JVM. Only an old launcher script read it. Newer images start the application without that script. So every flag in that variable is dropped silently. This includes heap, garbage-collector and driver flags.

What to do.

  1. Pass flags through the variable the JVM itself reads.

  2. Know that setting it in a compose file or a chart replaces the image’s default. It does not add to it. A flag added for debugging can remove the image’s heap size.

What not to do. Do not assume every service is already moved. Several still pass flags the old way. An installation pinned to an older image still works, because that image has the launcher.

Who to ask. The team that owns the service. Zone: the software being installed.

Offline installs: what a successful load does and does not prove

This section lists what a successful offline load proves, and what it does not.

  • A successful load proves the archive was valid. It does not prove it had what this server needs. So the installer checks every image the manifest names after loading.

  • Some services are built on the target machine, not pulled. An archive without their base images fails too. The manifest is in every bundle, online or offline, and lists both kinds.

  • The SSH deploy does not carry image archives. An offline site is installed from the downloaded bundle. See the bundle.

  • An archive built before the current version record reads as "cannot be checked". It never reads as current. Build a new one if the versions changed. This deletes the old archive and pulls all images again. That is why it is not the main action.

Who to ask. It depends on the case. Zone: mixed.

The journal starts in late August 2026, not at the product’s start

What you see. An installation that runs at a customer has no history in the journal.

What it means. Nothing deletes from the journal. But it starts on the day it was first written. Some columns started later. An installation deployed before that day has no rows.

What to do.

  1. Compare any journal figure with the date the journal starts. The screens show that date.

What not to do. Do not read "No history" as "nothing happened". It means nobody recorded any.

Other records are deleted on a schedule. Assistant transcripts go after a month. Several telemetry tables go after three months. The journal itself is not deleted.

Who to ask. Nobody. Zone: Deployment Manager.

What to attach to a ticket

This section lists what to attach when you open a ticket.

For any Deployment Manager failure or unclassified failure, attach:

  • The deploy transcript. The panel keeps it, so you do not need to run again.

  • Diagnostics from the affected server(s), from the installation card (see Step 7. Check that it works). They contain container states and the last 300 log lines of each container. They also contain config-file owners, docker versions, and every .env setting. Secret values never leave the customer’s site. They are replaced with [MASKED] before the file is written. An empty secret shows as [EMPTY — no value was set].

  • What the in-app assistant said about the failure, if someone asked it. The panel’s bug-report button attaches this for you. See The in-app assistant.

For a failure in the installed software, attach the same diagnostics. Also attach the container’s own logs and its health-probe history. The owning team needs these.

Three of six Superset containers keep restarting

This section covers a Superset install where three of its six containers restart.

What you see. superset, superset-worker and superset-beat restart. Its database, Redis and nginx stay up.

What it means. The three restarting containers load the same application. So they fail together. It is one fault, not three. The known cause: the configuration read one set of variable names, and the environment gave another set. Every part of the database address was empty. The port became the literal text None.

ValueError: invalid literal for int() with base 10: 'None'

An installation generated by Deployment Manager cannot cause this. But a hand-edited superset_config.py on the server can.

What to do.

  1. Read the log of superset. The other two repeat its error.

  2. Compare the names superset_config.py reads with the names in the installation’s .env.

Who to ask. The team that owns Superset. Zone: the software being installed.