Skip to main content

Troubleshooting

This page covers the most common reasons an app fails to start, especially when you deploy your own Docker image. Most of these problems look the same from the outside: the container does not start and you see no logs.

My app crashes with no logs​

Empty logs are an important signal. If there are no logs at all, the container never started. The problem is not in your application code — it is in how the container is started.

Check these four things, in order:

  1. Command override — if you set a Command Override, it must start with the program binary. A wrong command means nothing runs. See Command override basics below.
  2. Image architecture — the image must be built for linux/amd64. An arm64-only image fails with exec format error and produces no logs. See exec format error.
  3. Mount path over the binary — if you mount a volume over the path where the program lives (for example /garage), the volume hides the binary and the container cannot start. See Volumes.
  4. Missing or moved config file — if the program needs a config file at a fixed path, make sure that file exists at that path (for example on a volume you attached).

If logs do appear but the app stops afterwards, the container started correctly. In that case read the logs — the problem is inside the application, not in the points above.

exec format error / architecture​

Hostim nodes run on the linux/amd64 (x86-64) architecture. An image built only for arm64 (for example, built on an Apple Silicon Mac) will not run. The container fails immediately with exec format error and shows no logs.

Check the architecture of an image:

docker inspect <image> --format '{{.Architecture}}'

If this prints arm64, the image will not run on Hostim.

Fix — build a multi-architecture image:

docker buildx build --platform linux/amd64,linux/arm64 -t <image> --push .

If you use Cloud Native Buildpacks (pack), build on an amd64 machine, because pack produces single-architecture images.

Command override basics​

The Command Override field replaces the image's start command completely. It replaces both the ENTRYPOINT and the CMD of the image — the image default is not used at all when this field is set.

Because of this:

  • The value must start with the program binary (for example /app/rauthy, rauthy, or /garage).
  • Do not write only arguments. Arguments alone have nothing to run and the container will not start.

Good examples:

rauthy serve --config-file /config/config.toml
/garage -c /etc/garage/garage.toml server

If you need shell features (pipes, &&, environment expansion), wrap the command in a shell:

sh -c "bundle exec rails db:prepare && exec bundle exec puma -C config/puma.rb"

Bad example (no binary, only flags — nothing starts):

--config-file /config/config.toml

See Advanced App Settings for where to set this field.

Still stuck?​

Use the support widget in the console. To help us answer fast, include:

  • the image name and tag,
  • the Command Override value (if any),
  • the mount paths of any volumes you attached.