The Deployer documentation
Creating & deploying a project

Credential files

Some apps read a file at run time: a Google service-account key, a database certificate authority (CA) certificate, a private key. A credential file is such a file, uploaded once and placed read-only inside the service that needs it, at the path you choose, optionally with an environment variable that points to it.

Add a file

Open the project's Files tab (next to your environment variables). You need permission to edit settings to add, replace or remove a file, and permission to see setting names to see the list.

  1. Choose the service the file belongs to.
  2. Upload the file. It is stored exactly as you uploaded it, byte for byte, with no change to line endings.
  3. Choose the path inside the container. We suggest /run/deployer/files/<name>.
  4. Optionally choose an environment variable that points at it, such as GOOGLE_APPLICATION_CREDENTIALS. If your app expects the certificate's text in the variable rather than a path (some database settings do), choose put the contents in the variable. That is available only for public items such as a CA certificate.

We read the upload to show you facts without showing the file: a service account's email and project, a certificate's name and expiry, a key's type. A file is stored encrypted and cannot be shown again; downloading it needs the right to see values and your account password.

Limits

  • 64 KiB per file, 16 files and 256 KiB per service.
  • A path must be absolute and clean, and cannot be a system path such as /etc/passwd, /proc, /dev or the app's own data folder.
  • Frontends and static sites have no running container, so they cannot take files.
  • Credential files cannot be sent through the AI chat. Use the Files tab.

What happens when you save

On a project that is already live, saving a file does not restart anything by itself. You see exactly which services would restart, and when you confirm, only those services are replaced, one at a time and without downtime: the new container starts next to the old one and must pass its health check before the old one stops. Nothing is rebuilt, and your other services and other projects are not touched. If the new container fails its health check, the old one keeps serving.

On a project that is not live yet, the files are placed by its first deployment.

Where the file lives

The file is placed in a folder only the server's administrator account can open, outside your code and outside every backup, and mounted read-only into your service. If the file is ever missing on the server, the service fails to start, loudly, instead of silently running without it. Check files compares what is on the server with what you stored and tells you if one is missing or changed; applying puts the stored one back.

Because files are not in backups, restoring a backup puts them back from The Deployer on the next deploy.

Removing or replacing

Removing a file takes it off the server on the next apply. Secure deletion on a server's disk is not guaranteed, so if a credential was exposed, rotate it at its issuer as well. Replacing a file needs your account password and a restart of the service that uses it.

Google accounts created since 2024 may not allow service-account keys by default. If creating one fails, the error names the organisation policy and who can lift it; a key-free option is not available yet.

Where this works

Credential files are placed on servers: a virtual machine in your cloud account or your own server. Managed container services such as App Runner, App Service and App Platform cannot hold them, and the Files tab says so before you choose a hosting plan.

Related