How to start flipt inside a Docker container

[AvanishCodes]

My flipt config looks like this:

server:
  host: 0.0.0.0
  http_port: 8080

log:
  level: debug

environments:
  env-name: # id
    name: "env identifier"
    default: true
    storage: "storage-1"


authentication:
  required: true
  exclude:
    evaluation: true
  session:
    domain: ${env:FLIPT_DOMAIN}
    storage:
      type: memory
    cleanup:
      grace_period: 24h
  methods:
    oidc:
      enabled: true
      email_matches:
        - "^username@domain\\.com$"
      providers:
        google:
          issuer_url: "https://accounts.google.com"
          client_id: ${env:FLIPT_GOOGLE_CLIENT_ID}
          client_secret: ${env:FLIPT_GOOGLE_CLIENT_SECRET}
          redirect_address: ${env:FLIPT_REDIRECT_ADDRESS}
          scopes:
            - openid
            - email
            - profile


storage:
  storage-1:
    remote: "https://git-subdomain.domain.com/team/repo.git"
    branch: "main"
    poll_interval: "30s"
    credentials: "github"
    backend:
      type: memory


credentials:
  github:
    type: ssh
    ssh:
      user: username
      private_key_path: ./id_ed25519
      private_key_bytes: <WHAT-WILL-GO-HERE?>

My Dockerfile:

# Build a custom Flipt image that includes your config file
FROM docker.flipt.io/flipt/flipt:v2

# Ensure config directory exists and copy your config in place
# Your workspace has config.yml; the container expects default.yml
RUN mkdir -p /etc/flipt/config
COPY config.yml /etc/flipt/config/default.yml
COPY id_ed25519 /etc/flipt/ssh/id_ed25519

# Expose the API/UI and Admin ports
EXPOSE 8080 9000

# Declare the data directory as a volume (for flags, audit logs, etc.)
VOLUME ["/var/opt/flipt"]

# Use the default entrypoint/cmd provided by the base image
# (No CMD needed here unless you want to override defaults)

However, I get the below error when I build my container and start it:

Error: loading configuration: credentials: github credentials: ssh credentials: ssh authentication credentials: password non-empty value is required

My questions:

1. Should the private_key_path key contain the file location from the host machine or the Docker container (I have tried the path inside the docker container, but that did not work either.
2. Is the key private_key_bytes required or optional? I do not know what exactly will go here?

An addition to the documentation is highly appreciated. If I can get answers to these questions, I'd like to do a PR for the same to the documentation. Lack of clarity here inhibits the adoption in a corporate setup that is protected by VPNs, firewalls and internal host mappings, where accessing the git repo is only possible via SSH.

[dosubot[bot]]

Hi @AvanishCodes! I'm Dosu and I’m helping the flipt team.

Here’s how to get SSH-based Git storage working with Flipt in Docker:

• The private_key_path must point to the location of the key inside the Docker container, not the host. For example, if you copy or mount your key to /etc/flipt/ssh/id_ed25519 in the container, set private_key_path: /etc/flipt/ssh/id_ed25519 in your config. Flipt looks for the file at runtime inside the container’s filesystem, not the host’s. Reference

• You only need to use one of private_key_path or private_key_bytes—not both. private_key_bytes is for providing the private key directly as a string (the full PEM-encoded key, usually via an environment variable or secret provider). If you use private_key_path, leave private_key_bytes unset. Reference

• The error password non-empty value is required means Flipt expects a passphrase for the SSH key. If your key is not encrypted, set password: "" (an empty string) in your config. If your key is encrypted, set password to the passphrase (ideally via an environment variable or secret provider). Reference

• Your SSH remote URL must be in SSH format (e.g., git@github.com:user/repo.git), not HTTPS, when using SSH credentials. Reference

• For best security and flexibility, use environment variables or a secrets provider for sensitive values like the private key or passphrase, and reference them in your config using ${env:VAR} or ${secret:...} syntax. Reference

There’s a documentation gap here—these details about SSH key usage, Docker paths, and the password field aren’t clearly covered. A PR adding a section on SSH Git credentials in Docker, with examples for both private_key_path and private_key_bytes, would be very helpful for others in similar environments.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[dosubot[bot]]

This error is caused by Flipt's current configuration validation, which always requires the SSH password field to be present and non-empty—even if your SSH private key does not have a passphrase. This is enforced in the code and confirmed by tests: if you set password: "", Flipt will still reject the config with the error you’re seeing. There is no supported way to use an unencrypted SSH key (no passphrase) without providing a dummy non-empty password, but that will likely cause authentication to fail at runtime as well. This is not standard SSH behavior and appears to be an oversight in Flipt’s validation logic, not an intentional security measure.

There is currently no workaround in configuration for this; a code change is needed to allow empty passwords for unencrypted keys. If you want to track or contribute to a fix, see the related discussion and validation logic here and here.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[erka]

Hey @AvanishCodes.I don’t think it’s possible to use an empty password, as you noticed. Is there any reason why you couldn't use password for ssh key?

[AvanishCodes]

Yes, I understood this.

In our current setup for other projects, we already use SSH keys that don't have a passphrase. We were looking to reuse those SSH keys.

[erka]

I guess you could just set the password on your key with ssh-keygen -p -f .../.ssh/id_ed25519 -P "" -N "YourNewPassphraseHere"

[AvanishCodes]

Yes, we can do that, but we were looking to reuse some keys.

Anyway, we were able to deploy using the passphrase authentication method.