Nabha Security Overview
This page describes how Varalix Digitech Solutions ("Varalix") protects the Nabha platform (app.nabha.cloud, mqtt.nabha.cloud). It states what is in place today. It is the document referred to as the "Security Overview" in the Terms of Service, the Privacy Policy and the Acceptable Use Policy, and it carries our vulnerability-disclosure policy (Section 8).
1. Hosting and data location
Nabha runs on Google Cloud in the asia-south1 (Mumbai, India) region, on a Kubernetes cluster spread across multiple zones in that region. Data at rest in Google Cloud storage and databases is encrypted by Google Cloud by default. Where data leaves India, and for what purpose, is listed on the sub-processors page.
2. Transport
- The web application and API are served over HTTPS only.
- Devices connect to the MQTT broker over TLS on port 8883 only; the plaintext port 1883 is not exposed to the internet. Certificate details for device trust stores are available from founder@nabha.cloud.
3. Identity and access
- Passwords are stored as salted bcrypt hashes and are never stored or logged in clear text.
- Sessions use HttpOnly, Secure, SameSite cookies; session tokens are not readable by page scripts.
- Repeated failed logins lock the account for a cooling-off period.
- Access inside an organisation is role-based; administrators control who can see and change what.
- MQTT access uses per-organisation credentials and per-device tokens issued in the app, which can be rotated or revoked by the organisation.
4. Tenant isolation
Every record is scoped to an organisation. The boundary is enforced in the database itself with PostgreSQL row-level security, not only in application code. One organisation's telemetry, dashboards, alarms and users are not visible to another.
5. Logging and monitoring
Authentication events, administrative changes and data-affecting actions are recorded in an audit log per organisation. Platform logs are monitored for errors and abuse. Retention follows the Privacy Policy.
6. Incident response
We maintain an incident-response procedure. Reportable incidents are notified to CERT-In within the time it requires. Customers affected by a personal-data breach are notified within 48 hours of our becoming aware of it, as set out in the Data Processing Addendum.
7. Shared responsibility
We are responsible for the security of the platform we operate. You are responsible for your devices, gateways and firmware, your network, the confidentiality and rotation of your MQTT credentials and device tokens, the strength and secrecy of your users' passwords, and who you grant access to within your organisation (Terms, Section 3.2).
8. Vulnerability disclosure
We welcome reports of security vulnerabilities in Nabha.
- Report to: founder@nabha.cloud. Our contact is also published at
/.well-known/security.txton nabha.cloud and varalix.com. - What to include: the affected host or feature, steps to reproduce, and the impact you believe it has.
- What we do: acknowledge within 3 business days, keep you informed while we fix it, and credit you if you wish once it is resolved.
- What we ask: give us reasonable time to fix before public disclosure; do not access, modify or delete data that is not yours; do not run denial-of-service, social-engineering or physical attacks; stop and report as soon as you can demonstrate the issue.
- Research conducted in good faith within these rules will not be treated as a breach of the Terms or the Acceptable Use Policy. We do not currently run a paid bug-bounty programme.
9. Changes
We update this page when our practices change. Version and date are shown at the top.