Back to Blog

Coomia DIP Private Deployment Trial Guide

Coomia DIP uses the website for trial requests, approval, and License issuance. A separate customer deployment repository delivers immutable image references, deployment manifests, and operating documentation. Customers do not need product source code and must not build images from the retired source-based deployment instructions.

Coomia DIPPublished on October 2, 20264 min read
Share this articleTwitter / X

Coomia DIP Private Deployment Trial Guide

Coomia DIP uses the website for trial requests, approval, and License issuance. A separate customer deployment repository delivers immutable image references, deployment manifests, and operating documentation. Customers do not need product source code and must not build images from the retired source-based deployment instructions.

#Trial workflow

  1. Register at the Coomia website↗ and submit a trial request.
  2. A Coomia administrator reviews the request, selects the trial duration, and issues the License.
  3. View the License under My Licenses and the approved immutable image references and guides in Deployment Center.
  4. After the customer package reaches GO, install by following this guide and the customer deployment repository.
  5. Activate online, or use the cluster fingerprint to download an environment-bound offline license.jwt.
  6. Complete administrator bootstrap, health checks, and core business smoke tests before starting the trial.

#Current delivery status

The current runtime-artifact candidate is trial.22. Its four first-party images passed security gates, SBOM generation, GHCR Public publication, and anonymous RepoDigest reads. The customer deployment repository pins the shared trial image digests, so standard users do not need to select or copy them from the website. Deployment Center lists images only for customer-specific deliveries.

The customer deployment repository remains PREPARED. Deployment Center shows the customer repository, installation guides, and release status to approved users while withholding the self-service archive until the complete Kubernetes installer, full-product regression, and human approval are complete.

The Kubernetes core workflow and application-level recovery passed isolated acceptance, but the customer repository is still a reference implementation for an existing cluster. Docker Compose is outside the current Kubernetes candidate scope.

#Docker Compose requirements (currently unavailable)

The Docker Compose target is a clean Linux amd64 host with:

  • 8 vCPUs or more
  • 16 GiB RAM or more
  • 50 GiB free disk or more
  • Docker Engine and Docker Compose v2
  • Network access to ghcr.io and https://coomia.com

Do not use the clean-install procedure on a host containing production data. Follow the dedicated upgrade, migration, backup, and recovery documentation instead.

#Installation after GO

Start a self-service installation only when both values are GO:

Plain Text
RELEASE_STATUS=GO
COMPOSE_STATUS=GO

Fetch the customer repository and verify its state:

Bash
git clone https://github.com/coomia-ai/coomia-platform-deploy.git
cd coomia-platform-deploy
grep -E '^(RELEASE_STATUS|COMPOSE_STATUS)=' RELEASE_STATUS
bash scripts/verify-package.sh --layout-only
bash scripts/preflight-linux.sh compose

Initialize private customer configuration:

Bash
bash scripts/init-config.sh
vi compose/.env

Enter all 12 immutable RepoDigests from the release catalog together with environment-specific domains and credentials. Never use a floating tag such as latest, and never commit or share compose/.env.

After configuration review and change approval, run:

Bash
bash install.sh compose

Installation, start, stop, and restart operations change the customer environment and require the customer's normal approval process. The customer repository installation guide↗ is authoritative.

#License activation

#Online activation

Enter the website-issued License key on the product License page. The product connects to https://coomia.com to bind the environment and synchronize authorization.

#Offline activation

  1. Copy the complete cluster fingerprint from the product startup log.
  2. Enter it under My Licenses on the website.
  3. Download the environment-bound license.jwt.
  4. Import and verify it by following the customer repository License guide↗.

The fingerprint must not be empty or replaced with placeholder text copied from the UI. An offline License is valid only for the environment to which it was issued.

#Acceptance checklist

At minimum, verify that:

  • UI and API are healthy and users can sign in;
  • first-administrator bootstrap completes;
  • License status, entitled modules, and expiry are correct;
  • data-source connections, synchronization, and pipelines run;
  • ontology modeling and object browsing work;
  • Flink jobs run and produce checkpoints;
  • the target trial scenarios for rules, events, actions, analytics, and AI agents pass.

When a trial License expires, business controls enter a restricted state. Running Flink jobs should create a final savepoint and then suspend automatically without deleting existing data. This expiry behavior passed vendor-isolated acceptance, but it does not replace full-product regression.

#Support

If deployment fails, run the redacted diagnostic collector supplied by the customer repository. Never publish compose/.env, License files, passwords, tokens, or complete business logs. When contacting Coomia, provide the version, RELEASE_STATUS, failure time, affected step, and redacted diagnostics.

Coomia DIP is proprietary software. All rights are reserved. Third-party components remain subject to their respective licenses.