Skip to content

Hosting

Kodik Hosting lets you publish an app from the current workspace to the Kodik cloud without leaving the IDE. The entire flow — from project analysis to a live URL — runs inside the Marketplace.

The Hosting app list and app-management actions use the configured Kodik backend. If your IDE points at a custom kodik.apiBaseUrl, app inventory, deployment history, logs, metrics, visibility, rename, redeploy, stop, and delete actions use that same backend.

Before publishing, Kodik analyzes the workspace and automatically detects:

  • Framework — React, Next.js, Vue, Astro, Django, FastAPI, and others
  • Runtime — Node.js, Python, and so on
  • Commands — dependency installation, build, and start commands
  • Port the application listens on
  • Healthcheck path used to verify readiness
  • Environment variables — required and optional

You can review and edit the detected values before deploying.

The Add new app flow saves a local analysis result in .kodik/hosting.toml. The file is a versioned local contract that keeps the linked app ID, latest deployment ID and URL, workspace path, detected runtime/build settings, port, healthcheck path, and required or optional environment-variable metadata. Re-analyzing updates the local project settings without losing the app link.

Analyze and Re-analyze open the guided chat workflow. The agent may inspect the project and create or update hosting files, so Hosting does not estimate analysis progress; it keeps the setup view available and watches .kodik/hosting.toml, .kodik/Dockerfile, and root Dockerfile until the saved local state becomes deployable. The chat workflow asks the agent to validate the production app locally and, when Docker is installed and the daemon is reachable, build the Docker image, start the container, verify the healthcheck, and clean up the verification container.

If the workspace is missing .kodik/Dockerfile or a root Dockerfile, Kodik keeps Analyze workspace and Re-analyze available so the agent can create or update hosting files, but it does not show Deploy until a valid Dockerfile exists. The preflight also checks the manifest version, status, port, Dockerfile path, and environment-variable names before marking the project deployable. If Docker is unavailable locally, analysis can still continue; if Docker is available but the image build, container start, or healthcheck fails, the agent records that failure as a blocker.

Publishing uploads your workspace as a source archive together with a Dockerfile: Kodik reads .kodik/Dockerfile (or a Dockerfile at the workspace root) to build the image, so add one before deploying. Redeploying re-uploads the linked workspace the same way, so the source and Dockerfile need to be present locally.

If analysis detects required environment variables, Deploy stays disabled until you set values for them. After an app exists, Redeploy is blocked until the corresponding required secrets exist on that app.

After analysis, click Deploy (or Host a project in the Marketplace header). Kodik:

  1. Queues the deployment
  2. Builds the image and installs dependencies
  3. Starts the application
  4. Verifies availability via the healthcheck
  5. Assigns a public URL
StatusDescription
BuildingBuilding the image, installing dependencies
StartingApplication is starting up
LiveApplication is running and accessible at the URL
ErrorDeployment ended with an error
IdleApplication is stopped

The Hosting tab shows all your apps as cards with a live preview thumbnail and status. For each app you can:

  • Redeploy — trigger a new deployment with the current code
  • Start / Stop — start or stop the application
  • Delete — remove a specific deployment or the entire app
  • Rename — give the app a new name
  • Relink workspace — point an existing hosted app at a moved or reopened local project folder

Search and status filters (All / Live / Building / Error / Idle) help you navigate when you have many projects.

For each deployment you can view:

  • Logs — the application’s output stream
  • CPU and Memory — current resource usage

When a deployment fails, Kodik groups the error into the most likely cause, such as missing secrets, Dockerfile or container configuration, install/build failure, healthcheck or port mismatch, or a startup crash.

Sensitive environment variable values are stored as per-app secrets. In the app settings you can add, update, and delete secrets. Secrets are never exposed in plain text or passed to the model.

Each app keeps a deployment history. You can browse past deployments, view their logs, and check their status.

Kodik treats the backend’s liveDeploymentId from the deployment history as the active deployment for the detail page. That is the deployment used for the current badge, logs, metrics, and Start / Stop actions; logs are still loaded separately when you open or refresh them.

Previous successful deployments can be rolled back from the deployment history. Rollback starts a new deployment based on that earlier version and keeps the app attached to the same workspace.