What would you like to see?
Introduce an optional environment variable to disable Thrust when running Password Pusher in Kubernetes-based environments.
For example:
When this variable is enabled, the web process would start Rails (or Puma) directly instead of wrapping it with bin/thrust.
Current behavior:
web: bundle exec bin/thrust bin/rails server
Proposed behavior when PWP_DISABLE_THRUST=true:
web: bundle exec rails server -b 0.0.0.0 -p ${TARGET_PORT}
(or the equivalent Puma command if preferred).
The default behavior would remain unchanged, ensuring full backward compatibility for existing Docker Compose deployments.
🔈 Motivation
During an upgrade from Password Pusher 1.62.1 to 1.63.4, we found that the introduction of Thrust makes the official container incompatible with platforms that enforce non-root containers, such as OpenShift and Kubernetes clusters using the Restricted Pod Security profile.
The current startup sequence launches:
bundle exec bin/thrust bin/rails server
Thrust attempts to bind to privileged ports (80/443), which results in the following error when running without elevated privileges:
Failed to start HTTP listener
listen tcp :80: bind: permission denied
The Rails application itself continues to use the internal application port (5100), so the failure occurs before Rails starts.
Platforms such as OpenShift and Kubernetes already provide ingress controllers, TLS termination, load balancing, and HTTP routing. In these environments, Thrust is typically unnecessary because these responsibilities are handled by the platform itself.
Making Thrust optional would:
- preserve the current behavior by default;
- improve compatibility with Kubernetes/OpenShift;
- eliminate the need to maintain custom container images;
- make Password Pusher easier to deploy on enterprise Kubernetes platforms.
🛰 Alternatives considered
Several alternatives were considered:
- Running the container as root or granting
CAP_NET_BIND_SERVICE (not recommended and generally not permitted in OpenShift).
- Building and maintaining a custom image that replaces the
Procfile to bypass Thrust.
- Overriding the container command to start Rails directly, which bypasses part of the initialization performed by the official entrypoint.
While these approaches work to varying degrees, they all require users to diverge from the official image.
An optional runtime configuration to disable Thrust would provide a cleaner and more maintainable solution without affecting existing users.
📎 Additional context
Some observations from testing:
- Password Pusher 1.62.1 runs successfully in OpenShift using the default Restricted Security Context.
- After upgrading to 1.63.4, startup fails before Rails initializes because Thrust attempts to listen on port 80.
- The container entrypoint already supports conditional behavior through environment variables (for example,
PWP_PUBLIC_GATEWAY), suggesting that another optional runtime flag would fit naturally within the existing architecture.
- The Rails application continues to expose its internal service on port 5100, so the issue appears to be isolated to the Thrust frontend.
This feature would improve compatibility not only with OpenShift, but also with any Kubernetes environment where containers are expected to run as non-root users without additional Linux capabilities.
✅ Checklist
What would you like to see?
Introduce an optional environment variable to disable Thrust when running Password Pusher in Kubernetes-based environments.
For example:
When this variable is enabled, the web process would start Rails (or Puma) directly instead of wrapping it with
bin/thrust.Current behavior:
Proposed behavior when
PWP_DISABLE_THRUST=true:(or the equivalent Puma command if preferred).
The default behavior would remain unchanged, ensuring full backward compatibility for existing Docker Compose deployments.
🔈 Motivation
During an upgrade from Password Pusher 1.62.1 to 1.63.4, we found that the introduction of Thrust makes the official container incompatible with platforms that enforce non-root containers, such as OpenShift and Kubernetes clusters using the Restricted Pod Security profile.
The current startup sequence launches:
Thrust attempts to bind to privileged ports (80/443), which results in the following error when running without elevated privileges:
The Rails application itself continues to use the internal application port (5100), so the failure occurs before Rails starts.
Platforms such as OpenShift and Kubernetes already provide ingress controllers, TLS termination, load balancing, and HTTP routing. In these environments, Thrust is typically unnecessary because these responsibilities are handled by the platform itself.
Making Thrust optional would:
🛰 Alternatives considered
Several alternatives were considered:
CAP_NET_BIND_SERVICE(not recommended and generally not permitted in OpenShift).Procfileto bypass Thrust.While these approaches work to varying degrees, they all require users to diverge from the official image.
An optional runtime configuration to disable Thrust would provide a cleaner and more maintainable solution without affecting existing users.
📎 Additional context
Some observations from testing:
PWP_PUBLIC_GATEWAY), suggesting that another optional runtime flag would fit naturally within the existing architecture.This feature would improve compatibility not only with OpenShift, but also with any Kubernetes environment where containers are expected to run as non-root users without additional Linux capabilities.
✅ Checklist