Skip to content

Tentacles Infrastructure

Purpose

This document defines the Tentacles infrastructure shape clearly enough to build the first business-scoped platform slice.

Infrastructure Principle

The project owner wants service separation at the infrastructure layer, but the deployment must still favor the fastest path to one working pilot.

That means:

  • separate shared-core services by container
  • do not create one stack per tenant
  • keep the first pilot on business-tagged infrastructure only

Shared-Core Containers

cbr-sh-waha01

Role:

  • temporary QR-based WhatsApp adapter
  • prototype ingress and egress for the first workflow

State:

  • created
  • software deployed
  • reachable on 10.0.0.58:3000
  • paired and authenticated
  • configured to post message and session.status events to the Tentacles intake webhook

Practical note:

This is intentionally temporary and should be replaced later by the official WhatsApp Cloud API path.

cbr-sh-n8n01

Role:

  • orchestration
  • queue handling
  • notifications
  • channel flows

State:

  • created
  • software deployed
  • reachable on 10.0.0.55:5678
  • production intake webhook active at:
  • http://10.0.0.55:5678/webhook/tentacles/waha-inbound
  • local operator queue API active at:
  • http://10.0.0.55:8081

cbr-sh-postgres01

Role:

  • relational data
  • queue state
  • tenant metadata

State:

  • created
  • software deployed
  • reachable on 10.0.0.53:5432

Practical note:

  • live and available
  • not yet used by the first Stage 2 intake path, which currently persists the prototype queue locally on cbr-sh-n8n01

cbr-sh-qdrant01

Role:

  • retrieval layer
  • knowledge search

State:

  • created
  • software deployed
  • reachable on 10.0.0.54:6333

cbr-sh-dify01

Role:

  • later agent application layer if needed

State:

  • created
  • software deferred

cbr-sh-langfuse01

Role:

  • later observability and trace review

State:

  • created
  • software deferred

V1 Deployment Order

  1. cbr-sh-postgres01
  2. cbr-sh-qdrant01
  3. cbr-sh-n8n01
  4. channel integrations
  5. booking integration
  6. optional cbr-sh-dify01
  7. optional cbr-sh-langfuse01

Tenant Model On Infrastructure

The first infrastructure build should support:

  • TV Mount Australia as the first active tenant
  • Tentacles as an internal platform tenant
  • Souza Hub as a later internal pilot on the same shared core

This should be done through application and data separation, not separate full stacks per tenant.

Channel And Integration Boundary

V1 infrastructure must support:

  • WhatsApp integration
  • email integration
  • Google Calendar integration for the TV Mount Australia pilot
  • operator notification path

Safety Rule

No Tentacles deployment work should be placed onto family-only guests.

Only business-tagged guests or business-scoped new guests are valid targets.

Naming Rule

Use:

  • cbr-sh-* for Canberra business prototypes
  • separate service-oriented names, not tenant-oriented names, for the shared core

Practical V1 Interpretation

Even though the full separated shape is the target, the first build is successful if:

  • the core containers exist
  • one working TV Mount Australia flow exists
  • the review queue is real
  • human notification works

That is more important than immediate platform completeness.

Stage 2 Prototype Shape

The current Stage 2 intake path is:

  1. WAHA receives the WhatsApp event on cbr-sh-waha01
  2. WAHA posts the event to cbr-sh-n8n01
  3. n8n normalizes the payload
  4. n8n pushes a review item into the local queue API
  5. n8n sends the holding response back through WAHA

This path has now been proven with synthetic webhook tests.