1. Service scope
Tucunar provides an operational signal runtime and an optional cloud control plane. The node receives normalized signals, stores raw operational events in the selected ClickHouse profile, evaluates configured rules and emits incidents or alerts. The console manages identity, organizations, node enrollment and summarized health information.
The service does not replace the customer's source systems, incident-management process, backups, network controls or operational decision-making.
2. Deployment profiles and data boundary
In an on-premise or air-gapped deployment, the customer controls the host, ClickHouse volume, network egress, backups and local raw data. Cloud reporting is optional and outbound-only. In a cloud-managed deployment, the parties must record the hosting region, operator, backup policy and applicable data annex in the order form.
Tucunar Cloud receives only the control-plane data and summarized heartbeats, rollups and incident lifecycle information required by the enabled features. Raw signal payloads remain in the selected node profile unless a later written agreement explicitly changes that boundary.
3. Customer responsibilities
- Provide lawful access to the source system and configure signals with correct tenant and entity identifiers.
- Protect enrollment credentials, alert destinations and host access, and rotate them when exposure is suspected.
- Maintain the customer-controlled Linux host, Docker/Compose or approved runtime, ClickHouse storage, backups and outbound network path.
- Define alert owners, maintenance windows, escalation rules and the conditions that constitute a successful pilot.
- Do not send credentials, unnecessary personal data or prohibited content in signal payloads.
4. Availability, support and changes
Availability targets, support hours, severities, response times, maintenance windows and exclusions must be stated in the applicable order form or support schedule. Draft SLOs are measurement objectives, not a contractual warranty until approved and monitored.
Tucunar may update the service, node image or console while preserving the documented compatibility contract. Schema changes and customer-hosted upgrades require a versioned release, backup and rollback plan.
5. Billing, suspension and termination
Pricing, included usage, installation, support, taxes, renewal and cancellation are defined by the applicable order form or published catalog. The initial pilot model is a manual monthly renewal using a one-time payment preference; it must not be read as automatic recurring billing.
Access may be suspended for non-payment, security risk, unlawful use or a material breach, subject to the notice and cure process agreed by the parties. Termination must specify export, deletion, backup and access-revocation steps.
6. Confidentiality, security and responsibility
Each party remains responsible for protecting confidential information under its control. Tucunar documents authorization, token hashing, signed alerts, outbound-only reporting and data minimization, but customer-specific security requirements, SAML/MFA, mTLS, secret-manager integration and penetration testing must be agreed separately when required.
The parties must define ownership of customer data, permitted support access, subprocessors, incident notification, liability limits and any regulated-data restrictions before production use.
7. Open contracting fields
Complete before signature: legal entity and address, customer and Tucunar contacts, plan and price, currency and taxes, support schedule, data-processing terms, retention/deletion annex, hosting region, governing law and dispute process.