nabinav/deployhub

Purpose and entry points

DeployHub is a Go backend for repository-driven container deployments: GitHub source is connected, built into Docker images, published to Google Artifact Registry, and run on Cloud Run. The process starts at main.go; HTTP-facing orchestration is concentrated in handler/, while background deployment execution is in worker/worker.go.

HTTP/API and user session boundary

Handlers expose authentication, repository selection, deployment initiation, project retrieval, logs, image versions, rollback, deletion, and proxy behavior. They translate dashboard/API requests into persistence records and queued deployment work.

• handler/auth.go

• handler/deployHandler.go

• handler/rollback.go

Authentication integrates OAuth and JWT cookies/tokens, separating external GitHub identity exchange from application session verification.

• auth/oauth.go

• jwt/create.go

• jwt/verify.go

Project and deployment persistence

The db package is the system of record for users, projects, deployment jobs/status, environment variables, image IDs, queues, and logs. Handlers and workers should cross this boundary rather than own state directly.

• db/init.go

• db/jobCreate.go

• db/updateProject.go

Deployment state supports lifecycle transitions and recovery-oriented operations such as rollback, project deletion, and image-version lookup.

• db/changeProjectStatus.go

• db/getDockerImageId.go

• db/log.go

Queue-driven deployment execution

A deploy request creates/updates persisted work, then Redis-backed queue operations feed the worker. worker/worker.go is the asynchronous control-plane stage that performs deployment work independently of the request lifecycle.

• redis/add.go

• db/updateQueue.go

• worker/worker.go

The worker’s input/output contract is represented by deployment and worker schemas.

• schema/deploySchema.go

• schema/workerSchema.go

Source-control integration

GitHub access covers OAuth, repository discovery/selection, and webhook registration for continuous deployment. Git operations are isolated from handler concerns.

• auth/oauth.go

• handler/repo.go

• cmd/git.go

Webhook support forms the inbound continuous-deployment boundary; source retrieval is handled separately before builds.

• webhook/addHook.go

• helper/getRepo.go

Build and cloud deployment pipeline

The deployment stage clones/prepares source, detects or uses project Docker configuration, executes Docker build/push operations, and deploys the resulting image to GCP Cloud Run. Cloud-specific deployment orchestration is centered in:

• deploy/deploy.go

• utils/docker.go

• helper/gcloudPublic.go

Shell/command execution is abstracted behind utilities, making Docker and gcloud invocation a material host-runtime dependency.

• utils/command.go

• utils/docker.go

Runtime configuration, observability, and operations

Per-project environment variables are persisted then serialized/injected into deployment execution, rather than requiring repository .env files.

• db/getProjectEnv.go

• utils/parse_env.go

• utils/env_string.go

Logs flow from deployment execution into persistent logging and are surfaced through handlers. Deployment management also includes public proxying, rollback, and deletion paths.

• log/logWriting.go

• handler/logHandler.go

• handler/proxy.go

Infrastructure envelope

The service runs as a Go container (Dockerfile) and is locally composed with dependent services (compose.yml). Its material external systems are GitHub, Docker, Google Artifact Registry/Cloud Run, Redis, and the database initialized through db/init.go.