Skip to content
  • GDPR-compliant
  • 100% hosting in Germany
  • Personal contact
  • Support included
  • Provisioning within 24 hours
Getting started & containers 3 min read

Setting environment variables and secrets correctly

Most images are configured using environment variables, such as the name of the database server, the username and the password. When you create a container, the wizard suggests the necessary details; mandatory fields are marked as such.

Step 2 of the wizard, showing the name, version, required fields and preview
When creating a container: required details for the image; the password is already marked as secret.

Changing variables later

  1. Open your project and click on the container.
  2. In the Settings tab, go to the Environment variables and secrets section.
  3. Change values directly in the row. Use Add variable to create a new row, and the bin icon to remove one.
  4. Click Save in the bar at the bottom.

Names consist of uppercase letters, numbers and underscores. Reserved names are PATH, HOME, USER, HOSTNAME as well as names beginning with SIT_, PODMAN_, CONTAINER_ or LD_.

Environment variables and secrets in a container’s settings, with a warning about an unprotected password
Variables and secrets: The saved password remains hidden; the editor flags any unprotected passwords.

The ‘Secret’ button

Mark passwords, tokens and keys as secret. Secret values are stored in encrypted form, are never displayed again after saving, and are passed to the container as a protected secret. They therefore appear neither in plain text in the configuration on the server nor in the user interface. Within the container itself, they are available as environment variables as usual.

  • A saved secret only shows ‘Saved - leave blank to keep’. If you enter a new value, it will replace the old one.
  • If a name sounds like a password or key, for example SMTP_PASSWORD, and if it is not marked as secret, the editor points this out. One click on Mark as secret fixes it.
  • Normal variables can be read by anyone with access to your project, such as team members.

Saving restarts the container

As soon as you make a change, a bar appears at the bottom showing the areas that have been modified. Saving applies the changes immediately: the container is recreated and restarted with the new configuration and will be briefly unavailable during this process. Data in volumes is retained. Click Discard to undo all unsaved changes.

Save bar with a note about the restart and about login details of database images
The save bar lists the areas that have been changed and indicates that a restart is required.

Important for database images

Many database images, such as MariaDB, MySQL or PostgreSQL, only evaluate login details (username, password, database) the first time they are started with an empty volume. If you subsequently change, for example, MARIADB_PASSWORD, the database will retain the old password. The application will then report a login error.

How to change a database password correctly:

  1. Change the password within the database itself, for example via the browser console (option) using the database’s own commands.
  2. Then enter the new password in the database variable and in the application variable, for example WORDPRESS_DB_PASSWORD.
  3. Save both containers.

For a new, empty installation, you can reinstall the database container instead. This will delete all data from its volumes - see the article Finding and fixing errors.

What counts as a secret?

Anything that grants access: passwords, API keys, tokens, private keys and login details for email or external services.

Can I view a saved secret again?
No. Secrets are never displayed again once they have been saved, not even to our team. Store your passwords in a password manager and set a new one if necessary.
Can a secret be seen inside the container?
Yes. Within the container, it is available as an environment variable, just like any other variable - this is the only way the application can use it.
Why does my application report a login error after a password change?
The database most likely only applied the password on its first start. Change the password in the database itself and then in both containers.

Was this article helpful?

New to SpeedIT Solutions?

Hosting where you know someone.

What you are reading here is what we put into practice for our customers every day. Based in Isernhagen since 2009 - with dedicated contact persons rather than a call centre.

  • 100% hosted in Germany
  • GDPR-compliant
  • Dedicated contact person
  • Provisioning within 24 hours
4.9 88 reviews on Expeero

Bester Hoster Überhaupt

Ich bin mit allem zu 100% zufrieden. Ich nutze diesen Anbietern schon jahrelang! Nie Probleme gehabt.
Michael G.Recommends us · 08/07/2026

100 % recommend us · Expeero

All reviews on HOSTtest (opens in a new window)

You might also be interested in:

Personal support

Of course, our support team is also happy to assist you personally. If you cannot find what you are looking for in our knowledge base or require personalised support, please do not hesitate to contact us. We’re here to help you and to ensure that your experience with our products and services is as smooth and enjoyable as possible.