Skip to main content

​
What is a process?

When you deploy a use case, the platform creates a process — the public, discoverable representation of your automation. Users can find, install, and run processes with their own credentials. Each process has three layers:

​
Process

The top-level entity. Represents your automation on the platform.

​
Visibility levels

​
Deployment template

An immutable snapshot of a specific version. When you deploy version 1.2, the platform stores a template containing all workflow data with placeholders still present (not yet replaced with real values). Templates are never modified after creation. A new deployment always creates a new template.

​
Process instance

A user’s personal installation of a process. Each user gets their own instance with isolated state and credentials.

​
Instance states

​
Dev/Prod environments

Process owners get automatic environment management:
  • First deploy: Creates a dev instance, activates it
  • Publish to prod: Use codika publish <templateId> to promote a deployment. Auto-creates a prod instance.
  • Redeploy to dev: Updates the dev instance with new workflows
By default, both dev and prod instances run simultaneously after publishing. Use --auto-toggle-dev-prod with the publish command to pause dev when prod is active. Use codika list executions <instanceId> to view recent executions for either environment — pass the dev or prod instance ID.

​
Rerunning a deployment without versioning

Sometimes you need to change deployment parameters (e.g., company name, language, timezone) without creating a new template version. The codika rerun deployment command handles this:
  • Parameters are merged — you only pass what changed; existing parameters keep their values
  • No new template — the instance continues running the same template version
  • Uses owner credentials — workflows are redeployed with the instance owner’s integration bindings
  • Retry failed deployments — failed instances can be retried without --force
This is useful after publishing to production when you need to adjust configuration, or when a deployment fails and you want to retry with the same or updated parameters.
See the codika rerun deployment reference for full details.

​
Deployment instance

The running copy of a process instance with real n8n workflow IDs. This is what connects your process instance to live workflows in n8n.

​
Deployment status flow

​
Deployment pipeline

When you run codika deploy use-case, the platform:
  1. Validates the request (authentication, format, required fields)
  2. Calculates version based on your version strategy (patch/minor/major)
  3. Creates a deployment template — an immutable version snapshot
  4. Creates or updates the process, process instance, and deployment instance
  5. Deploys to n8n — for each workflow:
    • Replaces all placeholders with real values (credentials, parameters, IDs)
    • Creates or updates the workflow in n8n
  6. Returns the deployment result (IDs, version, status)

​
Version updates

When a new version is published:
  • Pinned instances: Users are notified that an update is available and can choose when to apply it
  • Unpinned instances: Automatically updated to the new version — the platform creates a new deployment instance and updates the live workflows
If an automatic update fails, the instance falls back to showing “update available” for manual retry.

​
Public API access

Process instances with HTTP triggers expose a public API for triggering workflows and checking execution status. Authentication uses a per-instance API key passed via the X-API-Key header. The codika trigger and codika get execution commands wrap these endpoints — you don’t need to call them directly.