railiance-apps/docs/inter-hub-on-railiance01.md

inter-hub on railiance01

Interaction Hub deployment for https://hub.coulomb.social.

Companion source repo: coulomb/inter-hub. This repo owns the Railiance app Helm surface and operator targets, not the runtime application code.

Hosts and release surface

Server	IP	Role
Railiance01	92.205.62.239	Production k3s; deploy S5 apps here
CoulombCore	92.205.130.254	Bootstrap / prerelease only

Item	Value
Namespace	inter-hub
Helm release	inter-hub
Chart	charts/inter-hub
Values	helm/inter-hub-values.yaml
Image	gitea.coulomb.social/coulomb/inter-hub:<tag>
Secret	inter-hub-env
Production kubeconfig	~/.kube/config-hosteurope

Current evidence

Read-only checks on 2026-06-15 showed:

• Helm release inter-hub revision 2 is deployed in namespace inter-hub.
• helm get values reports image.tag: 11ff61c, image.pullPolicy: Always, and runMigrations: false.
• The live Deployment image is 92.205.130.254:32166/coulomb/inter-hub:790b5e5, so production image state has drifted from Helm values and from this repo's desired Gitea registry target.
• The pod is Running and certificate/inter-hub-tls is Ready on Railiance01.
• GET https://hub.coulomb.social/api/v2/hubs returned 200 unauthenticated, matching the public discovery contract.
• GET https://hub.coulomb.social/api/v2/widgets and GET https://hub.coulomb.social/api/v2/hub-registry returned 401 unauthenticated with invalid_api_key.
• OpenAPI is published at /api/v2/openapi.json; /openapi.json is not the Inter-Hub v2 OpenAPI route.
• gitea.coulomb.social/coulomb/inter-hub:5101eb5 returned manifest unknown on 2026-06-15, so production deploy must wait for the image publication gate to pass.

Deploy

Use the Railiance01 kubeconfig. The Makefile defaults to ~/.kube/config-hosteurope and fails fast when it is missing.

make inter-hub-render-baseline
INTER_HUB_IMAGE_TAG=5101eb5 make check-inter-hub-image
INTER_HUB_IMAGE_TAG=5101eb5 make inter-hub-dry-run
INTER_HUB_IMAGE_TAG=5101eb5 make inter-hub-server-dry-run
INTER_HUB_IMAGE_TAG=5101eb5 make inter-hub-deploy
make inter-hub-status

Deploy automation should pass the image tag without rewriting helm/inter-hub-values.yaml. The production deploy target requires this explicit tag and refuses to continue if the registry manifest does not exist:

INTER_HUB_IMAGE_TAG=5101eb5 make inter-hub-deploy

Use a tag at or after the commit that contains the required v2 bootstrap API routes and any required follow-up fix. The upstream inter-hub workplan names 5101eb5 for the API count-decoding fix needed by the current ops-hub bootstrap path; verify the actual registry tag before announcing rollout.

make inter-hub-render-baseline exists only for chart validation with the checked-in values file. Production-facing dry-runs and deploys must use an explicit INTER_HUB_IMAGE_TAG.

Workflow Dispatch

.gitea/workflows/inter-hub-production-deploy.yaml provides a manual production trigger. It requires:

• image_tag, the immutable inter-hub image tag to deploy;
• confirm, with the exact value deploy-inter-hub-production;
• an approved self-hosted runner with Railiance01 kubeconfig access at ~/.kube/config-hosteurope or an equivalent RAILIANCE01_KUBECONFIG override;
• registry access through skopeo, crane, docker manifest inspect, or the registry HTTP API.

The workflow runs the same local targets an attended operator would run:

1. make check-inter-hub-image
2. make inter-hub-server-dry-run
3. make inter-hub-deploy
4. make inter-hub-status
5. make inter-hub-smoke

If the image manifest is missing, stop and hand back to the inter-hub/forge image publication path. Do not run Helm against a tag that fails preflight.

Release verification

make inter-hub-release-info

This wraps the required non-secret inspection commands:

helm history inter-hub -n inter-hub
helm get values inter-hub -n inter-hub
kubectl describe deploy/inter-hub -n inter-hub
kubectl get pods -n inter-hub -o wide

Confirm the rendered deployment uses the intended immutable image tag and does not rely on a stale latest image.

The chart intentionally keeps the legacy Deployment and Service selector app=inter-hub because the live Helm release was created with that selector. Kubernetes treats Deployment selectors as immutable; do not change this selector during a normal in-place production upgrade.

Migration boundary

The Railiance app chart currently does not run inter-hub database migrations. Treat migration execution as an upstream inter-hub operator step and record the evidence before closing a production rollout. Do not describe migrations as automatic unless the chart grows an explicit init job/container or another committed migration mechanism.

Smoke checks

After rollout, the current v2 public-read/authenticated-write contract should be present:

make inter-hub-smoke

Expected results:

• GET https://hub.coulomb.social/api/v2/hubs returns 200 public discovery JSON.
• GET https://hub.coulomb.social/api/v2/widgets returns 401 without a key.
• GET https://hub.coulomb.social/api/v2/hub-registry returns 401 without a key.
• GET https://hub.coulomb.social/api/v2/openapi.json returns OpenAPI JSON listing /hubs, /hub-capability-manifests, /api-consumers, /policy-scopes, /widgets, and /hub-registry.