# Deployment — EKS Support Relay

## Target

| | |
|---|---|
| Host | `acmycar`, `18.168.156.244` (the Chatwoot host) |
| SSH | `ssh -i <maciek_priv> ubuntu@18.168.156.244` |
| Path | `/home/ubuntu/eks_relay` (a real git checkout of the Gogs repo) |
| Domain | `https://eks-relay.easyklima.com` |
| Reverse proxy | Traefik `traefik-traefik-1`, docker network `web` |
| DNS | Cloudflare zone `easyklima.com`, proxied A record |

The relay is co-located with Chatwoot rather than with Flowise: the Chatwoot
webhook is the latency-sensitive hop (Chatwoot waits for the `202`), while the
Flowise → `/tools/*` calls happen inside an already long-running LLM turn.

### Why `easyklima.com` and not `easyklima.pl`

`eksupport.easyklima.com` and `botek.easyklima.com` already live in the
`easyklima.com` Cloudflare zone and terminate on the same Traefik. Putting the
relay in the same zone keeps one certificate resolver, one WAF policy surface
and one set of DNS conventions. `easyklima.pl` points at the shop's origin and
would need separate Cloudflare and Traefik work for no benefit.

> Note: the zone has a wildcard `*.easyklima.com` CNAME pointing at the shop
> origin. Without an explicit A record, `eks-relay.easyklima.com` resolves to the
> **shop**, not to Chatwoot. The explicit record below is mandatory, not optional.

## 1. DNS (Cloudflare)

Create a proxied A record matching the `eksupport` pattern:

| Type | Name | Content | Proxy |
|---|---|---|---|
| A | `eks-relay` | `18.168.156.244` | Proxied (orange cloud) |

```bash
# CLOUDFLARE_TOKEN comes from the local secrets file — never inline it.
ZONE=3ff752c975f4bfc6286f0f357f306c2f
curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE/dns_records" \
  -H "Authorization: Bearer $CLOUDFLARE_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"type":"A","name":"eks-relay","content":"18.168.156.244","proxied":true,"ttl":1}'
```

Verify:

```bash
dig +short eks-relay.easyklima.com    # Cloudflare anycast IPs
```

### Cloudflare and automated POSTs

Cloudflare's managed challenge can block server-to-server POSTs from Chatwoot
and Flowise. If that happens, add a **narrow** WAF skip rule — scoped to this
hostname and these paths only, never a zone-wide bypass:

```
Expression:
(http.host eq "eks-relay.easyklima.com" and
 (starts_with(http.request.uri.path, "/webhooks/") or
  starts_with(http.request.uri.path, "/tools/")))

Action: Skip → Managed Rules, Bot Fight Mode, Rate limiting
```

The endpoints stay protected by their own bearer secrets; the skip rule only
removes Cloudflare's browser-oriented challenges.

## 2. Server checkout

```bash
ssh -i <key> ubuntu@18.168.156.244
git clone https://gogs.tenteg.es/aiac/eks_relay.git /home/ubuntu/eks_relay
cd /home/ubuntu/eks_relay
git config user.name  "Maciek"
git config user.email "maciek@aiac.local"
```

It is a normal checkout, so `git pull` and `git push` both work on the server.

## 3. Environment

```bash
cp .env.example .env
chmod 600 .env
# fill in the real values (migrated from the PHP relay's .env.php)
```

Required before first start: `CHATWOOT_API_TOKEN`, `FLOWISE_PREDICT_URL`,
`FLOWISE_API_KEY`, `WOOCOMMERCE_CONSUMER_KEY`, `WOOCOMMERCE_CONSUMER_SECRET`,
`RELAY_SHARED_SECRET`, `ADMIN_TOKEN`.

`RELAY_SHARED_SECRET` **must** stay identical to the value configured in Flowise
as `$vars.relay_shared_secret`, otherwise every tool call returns 401.

## 4. Start

```bash
cd /home/ubuntu/eks_relay
sudo docker compose config          # validate
sudo docker compose up -d --build
sudo docker compose ps
sudo docker compose logs -f relay
```

The `web` network already exists (Traefik owns it); the compose file joins it as
external.

## 5. Verify

```bash
curl -s https://eks-relay.easyklima.com/health | jq
curl -s https://eks-relay.easyklima.com/ready  | jq
```

Then run [`SMOKE_TEST.md`](SMOKE_TEST.md).

## 6. Updating

```bash
cd /home/ubuntu/eks_relay
git pull
sudo docker compose restart relay
```

No rebuild: the repo is bind-mounted and the entrypoint reinstalls dependencies
only when `package-lock.json` changed, regenerates the Prisma client only when
`prisma/schema.prisma` changed, and always applies pending migrations.

Rebuild (`--build`) only when the Dockerfile or its base image changes.

## Database

SQLite at `/home/ubuntu/eks_relay/data/eks_relay.db`, bind-mounted into the
container at `/app/data`. It is gitignored.

Back it up before a schema change:

```bash
cp data/eks_relay.db data/eks_relay.db.$(date +%F-%H%M)
```

Browse it via Prisma Studio over an SSH tunnel — see the README. Studio is
never routed through Traefik.

## Chatwoot webhook

Point the Chatwoot bot/webhook at:

```
https://eks-relay.easyklima.com/webhooks/chatwoot
```

Keep the old PHP URL noted until the Node relay has passed a real e-mail test;
switching back is a one-field change in the Chatwoot panel.

## Known follow-ups

- **`wp-plugins/eksrelay_api.php` is unauthenticated.** Its routes use
  `permission_callback => __return_true`. The relay already sends
  `Authorization: Bearer <WP_STORE_API_SECRET>` when that variable is set;
  enforcing it in the plugin is a separate, coordinated change on the shop's
  WordPress.
- **`npm audit` reports a high-severity advisory** in `deepmerge-ts`, reached
  through `@prisma/config` → `prisma`. That is the Prisma **CLI** dependency
  chain (build/migration time), not the runtime `@prisma/client` used to serve
  requests. The only offered fix downgrades Prisma to 6.12; the advisory is
  therefore accepted and tracked rather than force-fixed.