CoRE Business

AVoIP’s administration and managed routing extend SMS group access, provider accounts and DID/caller-ID configuration. The inbox and admin screens share a Material Design 2 specification.

AVoIP’s proposed Caller Intelligence & Call Protection design covers local call policy, business identity, provider quotas and staged Kamailio integration. It is documentation only; no service or routing is enabled.

AVoIP's SIP Core INFO routing guide documents DTMF delivery to Asterisk, the separate RTPEngine trickle ICE path, and safe live verification of voicemail navigation and ACK routing. The Flowroute SMS messaging stack provides a responsive conversation inbox, authenticated send API, and independent inbound webhook. YVR uses the global PostgreSQL service; the YXL desired state adds a separate SMS stack using its site-local PGPool frontend to the global database cluster, with distinct public hostnames. YXL rollout remains to be verified. AVoIP's Authentik admin group desired state declares the voip@ aliases on snd.fyi, resolvemy.host and writemy.codes through its LDAP group attributes while retaining shared SMS number assignments. The SIP Core remote hangup guide describes the separate Contact-alias loss caused by retransmitted answers. The native SIP-over-TLS troubleshooting guide covers public dialog Contacts, owner-flow reuse and retransmitted SDP. Home1's native-phone AVP/SDES compatibility setting is scoped to the Kamailio-facing FreeSWITCH profile and awaits a post-rollout call test. The AVoIP chart now includes an opt-in PostgreSQL-backed HA Kamailio registrar and FreeSWITCH call-control path. The YVR ApplicationSet selects Kamailio registration; live convergence and call acceptance require separate verification.

CoRE Business contains the application charts and manifests for the business and personal-service layer of the CoRE platform. It includes AI services, automation, communications, office and collaboration tools, mail, ERP, identity-integrated utilities and several legacy or experimental workloads.

This is live, environment-specific infrastructure. Manifests contain CoRE domains, cluster assumptions, secret-store references and custom resource types. They should not be applied to another Kubernetes environment without a complete review.

Deployment model

This repository supplies application implementations; fleet deployment is owned by CoRE Backplane. Argo CD ApplicationSets under Backplane's Apps/Business/ select clusters, choose a path in this repository and inject environment-specific values. Many use the argocd-lovely-plugin to combine Helm and Kustomize inputs.

The active AVoIP ApplicationSet also provisions a retained, cluster-local RWX sound library shared by its Asterisk and FreeSWITCH workloads. The editor is protected on Homer's hostname with the existing Authentik access group. See the sound library guide for its data path, recording format, access boundary and verification steps. AVoIP's default Kamailio and RTPEngine listeners use each pod's address so locally emitted Homer traces identify their source; see capture verification. The AVoIP registrar path now uses a pod-specific TLS profile for FreeSWITCH's extension bridge, which sends no SNI, and defaults Kamailio core logging to level 1. Kamailio uses private UDP NG control to RTPEngine with explicit command retries and periodic endpoint redetection after transient errors; see RTPEngine recovery. The AVoIP chart now declares Kamailio as named instances; its active site lists are supplied by the AVoIP ApplicationSet. The Admin catalog selects inbound DID destinations. Both sites currently send the voice DID to YVR extension 67 and the other DID to extension 66; YXL uses the authenticated inter-site link. Each DID has a post-answer fax detection switch, with existing records enabled by default. See the inbound routing guide. same guide for the managed call path and verification. The chart also has an opt-in private Kamailio route and YVR Asterisk-to-carrier NANP calling through the authenticated service path. A new desired-state change moves authorized YVR NANP calls through the HA FreeSWITCH Flowroute registration, while both sites register at their regional PoPs, inbound DIDs remain on Kamailio, and Kamailio/RTPEngine keep the carrier media path. FreeSWITCH includes its outbound codec preferences on the Flowroute leg so G.711 can be negotiated when the SIP Core leg uses another codec; see the outbound setup. An opt-in private registrar pilot now renders a site-local PostgreSQL service identity and schema migration, but credential issuance and live registration for the private registrar are still open. The AVoIP ApplicationSet enables the carrier mTLS transport at YXL and YVR using each site's existing Vault core-tls-vault issuer, and configures YVR account 7101 for standard NANP outbound calls with the YVR Asterisk DID as caller ID. The Flowroute registration uses the existing Vault record and the West Oregon regional PoP. The YVR public IVR callback uses the main voice DID; Kamailio normalizes a digits-only NANP From user before enforcing the provider's verified caller ID list. See the SIP Core callback route. The private registrar remains disabled. Certificate issuance and workload rollout require reconciliation. The configured YXL voice and FaxNumber routes use that carrier mTLS link to reach the YVR IVR and Asterisk respectively; see the inter-site transfer guide. The guide records the 2026-10-17 Flowroute to YXL to YVR call, the transaction-aware CANCEL correction, and FreeSWITCH's corrected inter-site header condition; an answered follow-up call is still required. Home1 does run the SIP Core WSS path with a three-replica Kamailio edge and the digest-pinned LF-heartbeat compatibility image; the dynamic registrar and first-party webphone work remains open. See the Home Assistant SIP Core status.

CoRE-Backplane Apps/Business ApplicationSet
  -> cluster-label selection
  -> path in CoRE-Business
  -> Lovely / Helm / Kustomize rendering
  -> target namespace
  -> Kubernetes resources and operators
  -> user-facing service

The presence of a chart here does not prove it is deployed. Start in the Backplane repository and find the active ApplicationSet that references the path. Some workloads are explicitly under Apps/Business/Legacy/; other directories may be inactive, transitional or manually deployed.

Repository areas

Area	Paths	Examples
AI and automation	AI/, Automation/, BusinessProcesses/	OpenWebUI, speech services, MCP integrations, n8n and workflow tooling.
Collaboration and productivity	Office/, Communication/, Projects/, Tasks/	Nextcloud, Collabora, Mattermost, Matrix, OpenProject and task services.
Identity-facing utilities	Passwords/, Desktop/, Terminal/, Tools/	Vaultwarden, Kasm, browser terminals, CyberChef and Draw.io.
Business systems	ERP/, Finances/, Analytics/, Medical/, Education/	ERPNext, finance, analytics, health and learning workloads.
Communications	Mail/, AVoIP/, Voice/	Mail, SIP, Asterisk, FreeSWITCH, conferencing and the standalone LiveKit WebRTC SFU.
Other application domains	Family/, Feeds/, Knowledge/, Sharing/, Ambient/, Browsers/	Knowledge, feeds, file sharing, ambient audio and browser automation.
Standalone/older manifests	Apps/, Avatars/, HPSchool/, LocalAI/	Raw manifests and earlier deployment layouts.
Experimental material	Testing/, TMP/	Validation workloads and temporary/legacy content.

Currently deployed charts

The following paths are referenced by non-legacy ApplicationSets in CoRE Backplane. Follow each chart README for its deployment inputs and operational notes:

Chart	Backplane owner	Deployment scope
AI	AI, AINode2	AI hub/MCP services, GPUStack with Authentik OIDC, a replicated CPU Speaches backend, and per-cluster LocalAI workers.
Automation	Automation	n8n with external database, Redis and S3 credentials.
Ambient	Ambient	Moodist ambient-sound service on selected infrastructure clusters.
Browsers	Browsers	Selenium Grid browser automation.
Landing	Landing	Forecastle application launchpad at mylogin.space, discovering exposed applications from selected namespaces.
Desktop	Desktops	GPU-backed LinuxServer Selkies desktops, including 120 FPS OrcaSlicer and separate NVIDIA/Intel Steam streams; NVIDIA Steam starts in Big Picture with H.264 locked, and all routes use Authentik proxy authentication.
Office	Office	Nextcloud and Collabora; the AVoIP chart provides its Talk high-performance backend.
Mail	Mail	Multi-site Postfix, Dovecot, Rspamd and Maddy mail stack with DKIM/DNS and optional SimpleLogin.
Projects	Projects	OpenProject with site-local PostgreSQL, generated temporary S3 credentials and persistent attachments.
Vaultwarden	VaultWarden	Password vault, database identity and secret synchronization.
Terminal	Terminal	Browser-accessible terminal workload.
CyberChef	Cyberchef	Public/private Gateway API route for CyberChef.
Draw.io	DrawIO	Public/private Gateway API route for Draw.io.
openGym	Fitness	Personal workout tracker at gym.mylogin.space, with retained Longhorn data, bundled exercise media, and a retained legacy media claim.
SnapOtter conversions	Conversions	Private Authentik-secured conversion service at conotter.mylogin.space, with PostgreSQL, Dragonfly and retained Longhorn data.
Fediverse social	Fediverse	Live federated-social stack currently serving Mastodon at mastodon.mylogin.space, with Bluesky support and room for PeerTube/Lemmy.

The Fediverse social stack is live at mastodon.mylogin.space under the Fediverse ApplicationSet, which targets core-home1-talos-prod in core-prod and renders through Lovely. Mastodon is the current production service; the chart also contains optional Bluesky PDS support, while PeerTube, Lemmy and related federated services are future additions to this stack. The live value layer supplies the Mastodon hostname, Gateway attachment and PostgreSQL/S3 provider names. It uses Authentik OIDC, site PostgreSQL, S3 media storage and Dragonfly. Mastodon web and Sidekiq share a 50Gi Longhorn RWX PVC for temporary uploads using the Home1 non-migratable storage class.

Work in progress

LinkStack is prepared at Social/Links using BJW-S Common, an official digest-pinned LinkStack image, a single SQLite-backed replica, retained Longhorn storage and a public Gateway API route. It has no active Backplane owner yet and requires a future single-cluster owner to inject site identity, hostname, notification address and TLS listener values.

Dawarich is deployed from Personal/History by the Personal History ApplicationSet, using BJW-S Common, a pinned upstream image, retained Longhorn import/storage PVCs, site-local Dragonfly, automatically derived site-local PostgreSQL and Authentik OIDC. The ApplicationSet supplies the site identity, production namespace, gateway listener and Lovely rendering layer.

See the repository guide for ownership discovery, configuration layers and change validation.

Platform integrations

Charts assume infrastructure supplied by CoRE Backplane, including:

• Argo CD and the Lovely rendering plugin.
• Gateway API and CoRE gateway/listener conventions.
• External Secrets secret stores such as mainvault-core, corevault-rootsecrets and older vault-backend references.
• CoRE Crossplane APIs such as User and Database resources.
• Authentik/OIDC, LDAP and platform-specific identity automation.
• Shared PostgreSQL, Redis/Dragonfly, S3-compatible storage, DNS, TLS, observability and persistent-storage services.

Secret references in Git are not secret values. Still review templates and rendered manifests for literal passwords, tokens or deployable defaults.

Agent and commit workflow

Agent guidance combines this repository's rules with the current CoRE Backplane guidance. Requested implementation work includes validation, narrowly scoped commits and normal pushes to the confirmed intended branch unless the user requests review only, uncommitted changes or a PR. Deployment requests also include scoped Argo CD reconciliation and downstream verification. Preserve unrelated work and inspect the full outgoing commit range before publishing.

Use type(scope): Summary commit subjects, with a lowercase type, the component's established capitalization and a sentence-case summary; for example, fix(AVoIP.Kamailio): Correct SIP routing. Follow the repository procedure for publishing and deployment. Documentation-only changes need no cluster sync.

Working with a chart

Before editing a path:

1. Find its owning ApplicationSet in CoRE Backplane's Apps/Business/ tree.
2. Record the selected clusters, destination namespace, renderer and injected values or patches.
3. Inspect Chart.yaml, values.yaml, templates/, kustomization.yaml, raw resources and any embedded configuration together.
4. Confirm the required CRDs, operators, secret stores, gateways, databases and storage classes exist on the target cluster.
5. Render representative output, then review secrets, routes, selectors, namespaces, persistent data and deletion behavior.
6. Reconcile through Argo CD and observe downstream controllers plus the user-facing service.

For a conventional Helm-only chart, the local baseline is:

chart='AI'
helm dependency build "$chart"
helm lint "$chart"
helm template core-business "$chart" --values "$chart/values.yaml" >/tmp/core-business-rendered.yaml
git diff --check

Add the value layers injected by the owning ApplicationSet before treating the render as representative. If the path also has a kustomization.yaml, remote resources or Lovely patches, reproduce that composition order and inspect the complete result. Do not apply the temporary render directly to a cluster.

Current limitations

• There is no repository-wide automated chart-render or schema-validation workflow.
• Several dependencies refer to archived chart repositories, old versions or version ranges and require migration before a routine upgrade.
• Active, legacy and experimental directories are not labeled consistently in this repository; Backplane ownership is the best deployment indicator.
• Some large values/templates contain application configuration and embedded languages that need validation beyond YAML parsing.
• Site-specific hostnames and platform API dependencies limit portability.

Documentation

• CoRE-Business architecture and long-term plan
• CoRE-Business implementation backlog
• Repository and deployment guide
• AI stack
• CoRE Backplane architecture
• CoRE Backplane operations

Where documentation and manifests differ, the manifests, owning Backplane ApplicationSet and observed controller state are authoritative.

AVoIP administration is enabled by the Backplane owner on YVR and YXL, with SMS running in YVR and selected for YXL rollout, and managed SIP routing enabled. DNS-only admin aliases use the existing site HTTPS gateway names; the routes require Authentik. See deployment and rollback.