Kubernetes cluster

Artemis combines public Helm charts (mostly Bitnami) with proprietary charts. A cross-platform CLI (Node.js, bundling kubectl, helm, and skopeo) handles configuration and deployment.

Loading latest release…

Review the prerequisites before starting.

1. Supported clusters

Cloud: AWS, Azure, GCP, Intel Developer Cloud, OpenShift.
On-prem: Kubeadm, K3s/K3d, MicroK8s, OKD, or any conformant cluster.

2. Latest artifacts

Loading latest release…

Pick the binary matching your control machine. Save it as cli (or cli.exe on Windows) and chmod +x on Linux/macOS.

3. Transfer images to an internal registry

Air-gapped and locked-down clusters pull every container image from your own registry instead of from TurinTech's. The transfer.sh helper reads the same Container images list shown under latest artifacts, then copies all required images into the target registry under a turintech/ namespace, so you don't have to enumerate or tag images by hand. Pass --type kubernetes to select the Kubernetes image set.

Run it from a host that can reach both the source images and your internal registry (for fully air-gapped sites, this is typically a connected "jump" host or a DMZ mirror):

curl -fsSL https://turintech.github.io/artemis-deployment/transfer.sh | bash -s -- --target myregistry.internal:5000 --type kubernetes

The script verifies access to both registries (prompting you to log in with your TurinTech credentials if needed), prints the full source → target transfer plan for confirmation, then copies each image.

Options

Flag	Description
`-t, --target`	Target registry, e.g. `myregistry.internal:5000` (required)
`-T, --type`	Image set to transfer: `docker` or `kubernetes` (required)
`-m, --method`	Transfer method: `crane` (default) or `docker`
`-y, --yes`	Skip all confirmation prompts; fails if not already logged in
`-h, --help`	Show usage

Transfer methods

crane (default): copies images registry-to-registry without storing them locally, so no large local disk or running Docker daemon is required. crane is downloaded automatically if it isn't already on PATH.
docker: uses docker pull / tag / push. Requires a running Docker daemon but no extra tooling.

Non-interactive (CI / scripted)

curl -fsSL https://turintech.github.io/artemis-deployment/transfer.sh | bash -s -- --target myregistry.internal:5000 --type kubernetes --method docker --yes

After the transfer

Point the deployment at your registry with the following overrides in .configrc.json (see Installation step 6), then deploy with --env offline:

{
  "OVERRIDE": {
    "REGISTRY": "myregistry.internal:5000",
    "SERVICES_REGISTRY": "myregistry.internal:5000/turintech"
  }
}

4. Installation

On-prem clusters pull every image from your own internal registry. The --env offline flag selects this environment, which resolves images against the registry configured in .configrc.json. Run the steps below from a machine with kubectl access to the target cluster.

Provision a cluster matching the hardware requirements.
Download the latest CLI from latest artifacts and run the remaining steps from its folder.
Air-gapped environments: transfer every image listed above into your internal registry. See Transfer images to an internal registry.
Verify cluster connectivity:
```
./cli config cluster
```

Authenticate with the image registry:

./cli config registry-auth --env offline -u <user> -p <token>

Air-gapped environments: edit .configrc.json to point at your internal registry (these values match those printed by the transfer script):
```
{
  "OVERRIDE": {
    "REGISTRY": "your.internal.registry:port",
    "SERVICES_REGISTRY": "your.internal.registry:port/turintech"
  }
}
```
On an OpenShift cluster, also enable OpenShift mode (overrides can be combined in a single file):
```
{
  "OVERRIDE": {
    "OPENSHIFT": "true"
  }
}
```
Deploy:
```
./cli deploy up --env offline
```
Open Artemis at http://<node-ip>:80 (or your load-balancer URL).

5. Expose Artemis (optional)

If your cluster has an ingress controller available, expose Artemis through it instead of using the node IP.

Apply an Ingress resource pointing at the artemis-proxy service. Replace <namespace> with your Artemis namespace and artemis.domain.foo with the hostname you want to use. Add TLS, annotations, or ingressClassName as required by your controller.

kubectl apply -n <namespace> -f - <<'EOF'
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: artemis-proxy-ingress
spec:
  rules:
    - host: artemis.domain.foo
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: artemis-proxy
                port:
                  number: 80
EOF

Switch the proxy service to ClusterIP so traffic flows through the Ingress only. Add the override to .configrc.json:
```
{
  "OVERRIDE": {
    "PROXY_SERVICE_TYPE": "ClusterIP"
  }
}
```
Re-deploy the proxy to pick up the new service type:
```
./cli deploy up -f proxy
```

6. LLM providers

Add the keys for the providers you use under OVERRIDE in .configrc.json. Only configure the blocks for the providers you actually use.

Bedrock

{
  "OVERRIDE": {
    "ARTEMIS_BEDROCK_REGION": "eu-central-1",
    "ARTEMIS_BEDROCK_API_KEY": "<value>",
    "ARTEMIS_BEDROCK_ANTHROPIC_REGION": "<value>"
  }
}

Vertex

{
  "OVERRIDE": {
    "ARTEMIS_VERTEX_PRIVATE_KEY": "<value>",
    "ARTEMIS_VERTEX_PROJECT": "<value>",
    "ARTEMIS_VERTEX_EMAIL": "<value>",
    "VERTEX_SERVICE_ACCOUNT_SECRET_NAME": "vertex-key"
  }
}

For Vertex via service account file, create a Kubernetes secret vertex-key with key vertex-key.json and set VERTEX_SERVICE_ACCOUNT_SECRET_NAME=vertex-key.

OpenAI / Azure Foundry

ARTEMIS_OPENAI_TYPE selects the provider. It defaults to openai; set it to azure for Azure Foundry.

Official OpenAI

{
  "OVERRIDE": {
    "ARTEMIS_OPENAI_KEY": "<value>"
  }
}

Azure Foundry (OpenAI models)

{
  "OVERRIDE": {
    "ARTEMIS_OPENAI_TYPE": "azure",
    "ARTEMIS_OPENAI_URL": "<value>",
    "ARTEMIS_OPENAI_KEY": "<value>"
  }
}

Azure Foundry (Claude models)

{
  "OVERRIDE": {
    "ARTEMIS_AZURE_AI_URL": "<value>",
    "ARTEMIS_AZURE_AI_KEY": "<value>"
  }
}

Optional connection settings (OpenAI)

{
  "OVERRIDE": {
    "ARTEMIS_OPENAI_NO_SSL_VERIFY": "true",
    "OPENAI_SSL_CA_SECRET_NAME": "openai-certs"
  }
}

For OpenAI with a custom CA, create a secret openai-certs with key ca.crt and set OPENAI_SSL_CA_SECRET_NAME=openai-certs.

Anthropic

{
  "OVERRIDE": {
    "ARTEMIS_ANTHROPIC_KEY": "<value>"
  }
}

Cohere

{
  "OVERRIDE": {
    "ARTEMIS_COHERE_KEY": "<value>"
  }
}

Deepseek

{
  "OVERRIDE": {
    "ARTEMIS_DEEPSEEK_KEY": "<value>"
  }
}

7. CLI reference

The deployment CLI groups commands under a few top-level verbs and shares a small set of flags. The most common ones are listed here. Run ./cli --help or ./cli <command> --help for the full reference.

Commands

Command	Purpose
`./cli config cluster`	Verify the CLI can reach the target Kubernetes cluster.
`./cli config registry-auth`	Save image-registry credentials for the chosen environment.
`./cli bundle images`	List the container images this release will install.
`./cli deploy up`	Install or upgrade Artemis components on the cluster.

Flags

Flag	Applies to	Description
`--env offline`	`config registry-auth`, `deploy up`	Selects the `offline` environment profile, which resolves images against your internal registry per `.configrc.json`.
`-u`, `-p`	`config registry-auth`	Registry username and password (or token).
`-g <group>`	`deploy up`	Limit the deploy to a component group. Repeatable. Common groups: `worker`, `component`. Omit to reconcile the entire stack.
`-f <component>`	`deploy up`	Limit the deploy to a single component (e.g. `proxy`). Useful after a targeted override like `PROXY_SERVICE_TYPE`.

8. Update

Download the latest CLI from latest artifacts. Copy the .configrc.json from your previous deployment into the same folder as the new CLI so your registry and override settings persist across the upgrade.
Air-gapped environments: mirror the new release's images to your internal registry. Re-run the transfer script to copy them across.
Delete the existing assets folder, which sits next to the cli binary. It is safe to remove; the CLI regenerates it on the next deploy. Do not delete .configrc.json in the same folder, as it holds your personalised deployment configuration (registry, overrides, and provider keys) and is not regenerated.
Apply the update: ./cli deploy up -g worker -g component

note
./cli deploy up -g worker -g component upgrades only the Artemis workers and application components, leaving shared infrastructure (databases, MinIO, Redis, etc.) untouched. This is the recommended path for routine version upgrades.
./cli deploy up (no flags) reconciles the entire stack, including bundled infrastructure. Use it for a fresh install or when a release explicitly requires infrastructure changes.

1. Supported clusters​

2. Latest artifacts​

3. Transfer images to an internal registry​

Options​

Transfer methods​

Non-interactive (CI / scripted)​

After the transfer​

4. Installation​

5. Expose Artemis (optional)​

6. LLM providers​

Bedrock​

Vertex​

OpenAI / Azure Foundry​

Official OpenAI​

Azure Foundry (OpenAI models)​

Azure Foundry (Claude models)​

Optional connection settings (OpenAI)​

Anthropic​

Cohere​

Deepseek​

7. CLI reference​

Commands​

Flags​

8. Update​