Skip to main content

Advanced App Settings

Hostim.dev lets you control important settings for each app, including environment variables, CPU and memory scaling, and access to services like databases and volumes.

These options help you fine-tune how your app runs.

Environment variables​

You can define environment variables at the app or project level.

  • App-level variables override project values
  • Useful for secrets, configuration, or feature flags

To set environment variables:

  1. Open your app in the dashboard
  2. Go to the Envs tab
  3. Add or edit key-value pairs

Any database or Redis service you create automatically exposes environment variables for its connection details. The names are based on the service name so they can be easily referenced in your app configuration. For example, if you add a MySQL database named blog, the variables BLOG_MYSQL_HOST, BLOG_MYSQL_PORT, BLOG_MYSQL_DATABASE, BLOG_MYSQL_USER and BLOG_MYSQL_PASSWORD become available. You can interpolate these in other environment variables using the $(VAR_NAME) syntax:

If you add a Redis store named cache, you'll see CACHE_REDIS_HOST, CACHE_REDIS_DB and CACHE_REDIS_PORT.

EBK_DATABASE_HOST=$(BLOG_MYSQL_HOST):$(BLOG_MYSQL_PORT)
EBK_DATABASE_NAME=$(BLOG_MYSQL_DATABASE)
EBK_DATABASE_USER=$(BLOG_MYSQL_USER)
EBK_DATABASE_PASSWD=$(BLOG_MYSQL_PASSWORD)

Command override​

The Command Override field lets you change the command that starts your container. Leave it empty to use the image default.

When you set it, it replaces the image start command completely — both the ENTRYPOINT and the CMD of the image. The image default is not used at all.

Because of this, the value must start with the program binary, not with arguments only:

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

If you need shell features like pipes or &&, wrap the command in a shell:

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

A wrong command override is a common reason an app starts with no logs. See Troubleshooting.

Health checks​

A health check tells Hostim.dev when your app is actually ready to receive traffic, instead of assuming it's ready as soon as the container starts. This avoids downtime during redeploys and restarts.

If you set a health check path, Hostim waits for it to return a 200 response before routing traffic to the new instance and taking the old one down. If you don't set one, Hostim assumes the app is ready as soon as the container starts, so requests can hit it before it's actually warmed up (loading a cache, running migrations, connecting to a database).

To set a health check path:

  1. Open your app and go to Edit.
  2. Under HTTP Service, make sure Does this app have HTTP Service? is checked.
  3. Fill in Health check path, for example /health.
  4. Click Update App.

Requirements:

  • The path must start with /.
  • HTTP Service must be enabled (a health check path requires an HTTP port).

Leave the field empty to disable health checks.

Scaling and resources​

Each app runs with dedicated CPU and memory limits.

You can:

  • Scale vertically by selecting a different plan (CPU and memory)
  • Scale horizontally by adding more replicas

To adjust scaling:

  1. Open the app page
  2. Click on Edit
  3. Choose the desired plan
  4. Choose the number of replicas
  5. Click Update App

Connecting services​

Apps can connect to services inside the same project:

These connections use internal networking, so no public internet access is required between services.

Volumes​

If your app needs to store files, you can mount a volume:

  • Volumes are persistent across deployments
  • They can be resized or removed later

See Volumes for setup steps.