A deployment diff lets you review image changes, public ports and volume mount paths before applying them. These details affect which code runs, who can reach it and where it reads its data.
Hakopod uses an application TOML file to describe those decisions. The dashboard can help you prepare the file, and Git can keep it alongside the code. You can inspect the resulting configuration before deploying it.
Start with a small application
The CLI initializer creates a minimal HTTP service:
schema_version = 1
name = "hello"
[services.web]
image = "nginxinc/nginx-unprivileged:stable-alpine"
port = 8080
public = trueThis is a complete starter configuration. The service listens on container port 8080, and public = true requests HTTP ingress. It does not publish port 8080 directly on the host or expose a custom TCP protocol.
An image tag is a convenient input, but it can move. Hakopod resolves the image to a digest during deployment so the resulting release points at a specific artifact. Keep that distinction in mind when you compare the file you wrote with an applied configuration.
Give plain variables and secrets different jobs
A log level belongs in a normal environment variable. A database password belongs in the secret store, with a reference in the application file. A service receives only the secret bindings you declare for it.
That keeps secret values out of a configuration diff, but it does not make deployment permission harmless. Someone who can deploy code to a service can deploy code that reads the service’s injected credentials. Choose deployment grants with that in mind.
Separate development, staging and production scopes also matter. A variable named DATABASE_URL is not evidence that two environments should share a database. Set up each environment deliberately; selecting a different environment does not copy its data or secrets.
Read the plan, then follow the result
Once you have logged into your own installation and selected a project, the ordinary CLI workflow is:
hakopod validate --file hakopod.toml
hakopod plan --file hakopod.toml
hakopod deploy --file hakopod.toml --waitValidation checks the file locally. The plan shows normalized configuration, a diff, warnings and resource profiles. Deployment gets a fresh plan and submits its expected application revision. The earlier plan command does not save a review token for a later CLI call.
If someone changes the application before your expected revision is accepted, review the new state. The conflict prevents your change from silently replacing work you have not reviewed.
Acceptance and readiness are different stages. The server stores accepted work durably and continues after a browser closes. You still need to follow the rollout. A pod can fail to schedule, fail to pull its image or fail a readiness check after the request was accepted.
Connect a repository when the workflow is clear
A repository binding identifies a provider, repository, branch and TOML path. Hakopod resolves the source commit and reads that exact file. A monorepo can therefore keep its deployment file somewhere more useful than the repository root.
Repository sync and image builds are separate choices. You can sync a file that already names images, or configure a Dockerfile or buildpack workflow on GitHub or GitLab runners. Provider credentials, runner capacity and private registry pull access still need configuration.
Before enabling automatic deployment, make a manual change and follow it through the full loop: source, plan, accepted revision, rollout and current service health. That gives you a working reference when the next push arrives without someone watching the browser.
Follow your first application for the complete login and deployment steps, then read deployments and rollback for repository setup and revision behavior.