Canine: Git-Push Deployments and a Web Interface for Your Own Kubernetes Cluster

What Canine Solves and Who It Is For

Canine addresses a specific gap: Kubernetes provides powerful infrastructure primitives but a high operational surface area for developers who just want to deploy and scale an application. The README frames this directly: stop wrestling with kubectl and complex YAML manifests.

The target user is a developer or small engineering team that runs its own Kubernetes cluster, whether cloud-managed or on-premise, and wants a deployment experience closer to Heroku or Render. They want git-push deployments, a web UI for managing environment variables and scaling, and automatic SSL certificate provisioning, without writing or maintaining deployment YAML for every application.

Canine is self-hosted by design. Unlike cloud PaaS platforms, it runs on infrastructure the team controls. The README describes this as maintaining complete control over your infrastructure, with the ability to run Canine on any Kubernetes cluster including cloud, on-premise, or edge.

A Canine Cloud option with additional features for small teams is mentioned in the README with pricing details at canine.sh, but the open-source self-hosted version is the subject of the repository.

Core Features: Deployments, Services, Secrets, and Domains

Canine's feature table in the README covers ten capabilities.

Automated deployments use GitHub or GitLab webhooks to trigger a build and deploy on each push. Canine builds Docker images using either a Dockerfile in the repository or buildpacks, then handles the full deployment pipeline.

Service types include web services, background workers, and scheduled cron jobs. Each service type maps to a different Kubernetes workload configuration without the developer writing that configuration directly.

Resource constraints let users configure CPU, memory, and GPU limits per application through the web interface.

Custom domain management includes DNS integration and automatic SSL certificate provisioning. Environment variables and Kubernetes secrets are managed through the interface, with secrets stored as Kubernetes secrets rather than plaintext.

Persistent storage volumes are available for stateful applications and databases.

Multi-tenancy uses account-based isolation with team collaboration and access control. Enterprise SSO supports SAML, OIDC, and LDAP integration.

Custom pod templates allow advanced Kubernetes pod customisation via YAML configuration for teams that need to go beyond the defaults.

Installing Canine with Docker Compose

The minimum requirements are Docker v24.0.0 or higher and Docker Compose v2.0.0 or higher. The one-line installer covers the setup automatically:

curl -sSL https://canine.sh/install.sh | bash

For a manual installation:

git clone https://github.com/CanineHQ/canine.git
cd canine
echo "SECRET_KEY_BASE=$(openssl rand -hex 64)" > .env
docker compose up -d

After the containers start, open http://localhost:3000 in a browser. To run the web interface on a different port:

PORT=3456 docker compose up -d

The docker-compose.yml runs three services: a PostgreSQL 16 database, a Canine web process on the configured port, and a Good Job worker process for background job processing. Both the web and worker containers use the ghcr.io/caninehq/canine:latest image. The PostgreSQL data persists in a named Docker volume. The DOCKER_SOCKET environment variable defaults to /var/run/docker.sock, which Canine requires to build images locally.

How the Deployment Pipeline Works

Canine connects to a GitHub or GitLab repository via webhook. When a push arrives, Canine pulls the repository, builds a Docker image from the Dockerfile or from buildpacks if no Dockerfile is present, and pushes the image to the configured container registry. It then applies the update to the Kubernetes cluster using kubectl and Helm.

The Dockerfile in the repository embeds kubectl v1.31.0 and Helm v3.16.3 into the built image during the build stage. This means Canine uses those specific CLI versions to communicate with the Kubernetes cluster, regardless of the cluster's version. Compatibility between these bundled versions and the target cluster API version is a deployment concern.

The web interface shows deployment status in real-time via WebSocket connections, using the xterm.js terminal component for log streaming. Build logs, deployment events, and runtime logs are accessible from the application's page in the interface.

For the local Docker Compose deployment mode, the BOOT_MODE environment variable is set to local in docker-compose.yml. This mode is described in the docker-compose configuration as distinct from the standard Kubernetes deployment mode, using REMAP_LOCALHOST and DOCKER_SOCKET for local container orchestration.

Technology Stack and Repository Layout

Canine is a Ruby on Rails application. The .ruby-version file specifies Ruby 3.3.4. The Gemfile lists Rails dependencies. The frontend uses Hotwire (Turbo Rails and Stimulus), Tailwind CSS via PostCSS, DaisyUI for component styling, CodeMirror 6 for the YAML editor, and xterm.js for the terminal log viewer. The esbuild.config.mjs file handles JavaScript bundling. ApexCharts and Chart.js handle metrics visualisation.

The repository layout follows Rails conventions. The app/ directory contains models, controllers, views, and jobs. The db/ directory contains database migrations using Active Record. Background jobs use the Good Job library, which runs on top of PostgreSQL without requiring a separate queue backend like Redis or Sidekiq.

The swagger/ directory contains the API specification. The config/ directory holds Rails configuration including secrets management via Rails credentials. The install/ directory contains the installer scripts referenced in the one-line install command.

The Dockerfile builds for production using Ruby 3.3.4 slim as the base, installs kubectl and Helm during the build stage, and configures RUBY_YJIT_ENABLE=1 to enable the YJIT just-in-time compiler for improved throughput.

Limitations and Cases Where Canine Is the Wrong Fit

Canine requires a running Kubernetes cluster before it can deploy applications to one. It is not a Kubernetes installer or a cluster management tool. Teams without an existing cluster must provision one separately, which adds a prerequisite that cloud PaaS platforms do not impose.

The bundled kubectl v1.31.0 and Helm v3.16.3 versions in the Dockerfile may lag behind or be incompatible with the latest Kubernetes API versions. The README does not document a process for updating these versions between Canine releases.

The SSO features (SAML, OIDC, LDAP) are listed in the feature table but the README does not document their configuration. Users planning to rely on enterprise SSO need to check the documentation at docs.canine.sh before deploying.

For teams who want to avoid managing a Kubernetes cluster entirely, Render and Railway are alternatives that provide git-push deployments and managed infrastructure without a self-hosted cluster. Unlike Canine, those platforms run on managed cloud infrastructure and do not require Docker Compose or Kubernetes knowledge to get started. Canine's advantage over them is data locality and the absence of per-seat or per-resource pricing tied to a vendor.

The licence is Apache-2.0, which permits commercial use and modification without copyleft obligations.

Multi-Tenancy, Access Control, and Security Considerations

Canine supports multiple accounts with role-based access control and team collaboration. The LOCAL_MODE_PASSWORDLESS environment variable in the Docker Compose configuration is set to true for the default local install, which disables password authentication for the initial setup. The ALLOWED_HOSTNAME is set to a wildcard in the local configuration, accepting connections from any hostname. Both of these settings are appropriate for a local development environment and should be changed before exposing the installation to a network.

The SECRET_KEY_BASE is generated during installation with openssl rand -hex 64. The default docker-compose.yml sets a hardcoded CONFIG_ENCRYPTION_KEY for the core service, which should be replaced with a unique value per deployment.

The Dockerfile creates a non-root nextjs user and runs the application as that user in the production image, following standard container security practice. The production image uses Ruby slim with only runtime dependencies installed, reducing the attack surface compared to the builder stage image.

Editorial conclusion

Canine is a practical fit for engineering teams that already run Kubernetes and want a Heroku-style deployment layer on top of it without paying for a managed PaaS. The git-push workflow, the built-in domain and SSL management, and the SSO support make it a complete self-hosted alternative. The tradeoff is operational: you maintain the Kubernetes cluster, the Canine installation, and the PostgreSQL database behind it. Teams who find that tradeoff unacceptable, or who need stronger multi-tenant isolation guarantees than Canine documents, should evaluate a managed platform instead. Verify that your cluster version is compatible with the kubectl v1.31.0 and Helm v3.16.3 versions bundled in the Dockerfile before deploying. The last push was on 2026-09-24.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository