Skip to main content

Local Model Plus Outbound Delivery

Use this playbook when you want local or self-hosted inference but only need governed outbound delivery instead of a reply-loop service runtime. This page is intentionally narrow:
  • the model runtime stays local or self-hosted
  • delivery stays outbound-only
  • nothing here is documented as if it joins the runtime-backed gateway owner contract

When This Is The Right Playbook

  • local control over the model runtime matters more than hosted convenience
  • no inbound or reply-loop channel is required on day one
  • the team wants notifications, reports, or alerts delivered outward without overclaiming runtime support

Use A Different Playbook If

Step 1: Bring Up The Local Provider

Ollama example:
Health loop:
Operational note:
  • if the server effectively serves one production model, pin model explicitly instead of forcing catalog discovery drama

Step 2: Add One Outbound Surface

Webhook example:
Smoke-test it:
Email example:

Step 3: Keep The Boundary Truthful

Rules that matter:
  • webhook, email, Slack, Discord, Teams, and similar surfaces are outbound-only
  • they do not join the same reply-loop owner model as Feishu / Lark, Telegram, Matrix, or WeCom
  • do not route this setup description toward gateway run as if outbound-only delivery became a supervised runtime

Step 4: Adjust The Outbound HTTP Boundary When Needed

HTTP-backed outbound delivery blocks private or special-use hosts by default. If you intentionally target a private bridge or loopback service, widen that boundary explicitly:
Use that only when the private target is intentional.

Variants

Other local or self-hosted providers fit the same shape:
  • lm_studio
  • llamacpp
  • vllm
  • sglang
The key point is the same: local inference plus truthful outbound delivery is a valid public setup shape, but it is not the same thing as a shipped reply-loop runtime.

Troubleshooting

Continue Reading