About Hypernyx
Hypernyx, a product of Hirkania Technologies, is an IoT-based smart intrusion alarm solution. It is available in three models for different requirements and is designed for residential, business, and large-enterprise environments.
The Hypernyx mobile application lets users control their alarm devices remotely. Behind that straightforward experience is a platform that must securely and reliably manage device connectivity, product APIs, and message flows. For a security-related product, an infrastructure disruption is not merely a technical fault; it directly affects user trust and the reliability of the product itself.
The challenge: infrastructure for a product that must remain dependable
Hypernyx did not engage Dropp Tempo to rescue a failing legacy environment. The partnership began at the start of the project, and the real challenge was to design the infrastructure correctly before operational debt could accumulate.
Three requirements shaped the engineering decisions from day one: application and infrastructure security, continuous availability of critical services, and the ability to support a growing device fleet. The platform needed to tolerate isolated component failures, provide enough operational visibility for rapid diagnosis, and avoid unnecessary cost and complexity.
The business implications were equally clear. As more devices joined the platform, insufficient capacity planning, monitoring, or tested recovery procedures could slow product delivery and pull the development team away from new capabilities and into reactive operations.
Audit: turning business requirements into infrastructure decisions
In a greenfield project, an audit is not about finding faults in an existing architecture. Before issuing its proposal, Dropp Tempo assessed and documented product requirements, security sensitivity, expected capacity, service dependencies, failure scenarios, backup and disaster recovery needs, and the anticipated path of growth.
The outcome was not a shopping list of popular tools. It was a set of decisions aligned with the project’s risk profile and budget. Every component needed an operational reason to exist, and its ongoing maintenance cost had to be justified. This allowed the team to introduce high availability where it mattered without prematurely committing Hypernyx to a fully active-active design.
Engineering decision: high availability without over-engineering
A broad active-active architecture was one of the options considered. It could have increased the level of automation, but it would also have introduced more operational complexity, higher infrastructure cost, and a greater risk of unpredictable behavior during unstable conditions. For the project’s current scale and budget, that trade-off was not justified.
The selected architecture introduces redundancy across the API, IoT platform, MQTT messaging, and database layers. Data replication and regular backups reduce exposure to data loss. Failover is deliberately controlled: alerts notify the team, and the Incident Commander assesses the situation before authorizing a switch.
The manual decision point does not mean high availability is absent. It is a deliberate safeguard against repeated switching during intermittent failures. We therefore do not describe the system as having fully automatic failover or guaranteed zero downtime. What was implemented is multi-layer redundancy with a controlled recovery path.
Build: infrastructure for APIs, IoT, and MQTT
The initial infrastructure was delivered in approximately two months and continued to evolve alongside the product. Dropp Tempo designed the required environments, deployment path, MQTT communication layer, data replication, access controls, monitoring, and backup processes as parts of one operating system rather than isolated tasks.
Details of the broker, QoS, session management, and internal topology are intentionally withheld for security reasons. At the level that can be disclosed, the architecture is designed so that the loss of an individual microservice or isolated component does not necessarily cause a full platform outage. Operational events have generally remained limited to degraded service or disruption of a single component.
Calculations based on actual resource use at the current load indicate headroom for continued device growth. Because no formal load test has been performed, we do not present that assessment as validated throughput or guaranteed capacity. The defensible conclusion is that the environment was designed with future growth in mind and is continuously monitored as demand changes.
This diagram shows the general message path: from connected devices, through a secure entry point, over MQTT messaging, to the API services and data layer. Observability, security controls, and backup/disaster recovery apply across every layer as cross-cutting concerns; internal protocol and topology details are withheld for security reasons.
Security from design through daily operations
For Hypernyx, security was not a final pre-release checkpoint. Security controls were built into network design, administrative access, the delivery pipeline, and routine operations.
Network segmentation is enforced with pfSense, while ports and access paths are limited to what is operationally required. Administrative server access is routed through Teleport with two-factor authentication. Sensitive communications are protected with TLS, and RBAC, secrets management, hardening, patch management, and audit logging are part of the infrastructure operating model.
Within the software delivery chain, container images are scanned with Trivy and code is analyzed with SonarQube. These controls are not presented as a claim of absolute security. Their purpose is to reduce the attack surface, control privileged access, identify risks earlier, and make security improvement repeatable.
CI/CD and Infrastructure as Code
Infrastructure and service delivery should not depend on individual memory or a collection of manual commands. Dropp Tempo manages the environment through Infrastructure as Code and has implemented complete CI/CD pipelines with automated deployments for the project’s services.
Releases are performed regularly, and the team has a fast rollback path when a deployment does not behave as expected. Exact deployment frequency and rollback time are not presented as case study KPIs because the available figures are operational estimates rather than aggregated pipeline reports.
Adding a new service also follows a defined process: requirements are assessed, time and cost are estimated, and after approval the infrastructure is provisioned through IaC and the service enters the environment through the standard deployment path. This keeps product growth from disrupting the rhythm of operations.
Observability: from dashboards to operational response
Observability is more than installing dashboards. The Hypernyx environment monitors servers, resources, APIs, core endpoints, databases, replication, messaging, device connections, certificates, and backup execution.
Uptime Kuma checks the availability of core endpoints from outside the platform. Alerts reach the Dropp Tempo team through email and Rocket.Chat, while the client receives relevant notifications in Mattermost. This multi-channel route ensures that an alert does not remain trapped in a dashboard; it reaches the people responsible for acting on it.
In one event, the service responsible for sending notifications became unavailable. Real-time monitoring exposed the disruption, and the team restored the service before it developed into a broad platform outage. No exact MTTR is claimed for this event, but it demonstrates how observability was connected to operational response.
Testable backup and disaster recovery
The presence of backup files does not by itself prove that a system is recoverable. Alongside regular backups, Dropp Tempo periodically tests restoration and the disaster recovery scenario.
Failure, restore, disaster recovery, security, and rollback tests were also performed following the operational launch. The controlled tests met an RTO of 30 minutes and an RPO of one hour. These figures are test results rather than an unconditional promise for every possible incident, but they demonstrate that the recovery path exists beyond documentation.
Beyond the product platform: Hirkania Technologies’ operational infrastructure
Dropp Tempo’s scope is not limited to services directly used by the Hypernyx product. Hirkania Technologies also depends on internal platforms for day-to-day work, including GitLab, Nextcloud, n8n, Baserow, and Outline.
Dropp Tempo deploys and maintains the infrastructure behind these services as well. This broader scope prevents the product platform and corporate tools from becoming isolated operational islands, bringing security, backup, monitoring, and incident ownership into a consistent operating model.
Technical outcomes
- More than 1,000 active and test devices are present on the platform.
- Core endpoints have recorded uptime above 99.9%.
- Redundancy is implemented across the API, IoT platform, MQTT messaging, and database layers.
- An RTO of 30 minutes and an RPO of one hour were met in post-launch tests.
- Automated CI/CD and Infrastructure as Code make infrastructure delivery and service deployment repeatable.
- Multi-layer monitoring covers endpoints, APIs, replication, messaging, device connections, and backups.
- Periodic restore and disaster recovery testing is part of ongoing operations.
- Events have generally remained limited to partial degradation, with no major platform-wide incident recorded.
Business impact
From the beginning of product development, Hypernyx has had a clearly accountable team responsible for infrastructure—not a team that delivered the initial environment and stepped away, but one that retained ownership of monitoring, security, deployments, incident response, and recovery.
This operating model allows the product team to introduce services and capabilities through a standard path. Capacity planning for growth, 24/7 support with a response time under 30 minutes, and the containment of partial failures all reduce the operational risk of a product whose users depend on availability.
We do not attach unverified cost-saving or revenue-growth figures to this project. The defensible business outcome is a secure, observable, and supportable operational foundation for launching and growing the product.
Retain: five years of continuous responsibility
The partnership between Dropp and Hirkania Technologies began in 2021. It progressed from requirements assessment and infrastructure design through ongoing product development and testing, and it continued after the platform entered live operations.
Today, Dropp Tempo’s DevOps team collectively supports Hypernyx. Monitoring, logging, alerting, incident response, backup, disaster recovery, security, and the deployment of new services continue as ongoing responsibilities. Support is available 24/7, with a defined response time of under 30 minutes.
This is Retain in the Dropp Tempo model: the team that understands the reasoning behind the architecture remains responsible for its daily health and continued evolution. The result is infrastructure that grows with the product without turning every release into an emergency—what Dropp Tempo means by “ship in rhythm, not in panic.”
IoT infrastructure should be part of the trust in the product
For connected, security-sensitive products, infrastructure is an invisible but decisive layer of the user experience. It must tolerate isolated failures, control access, make service health visible, and provide a tested route to recovery.
The Hypernyx project shows that high availability does not always require the most complex architecture or complete automation. The right design is one aligned with the organization’s risk, budget, capacity, and operating capability—and supported by a team that remains accountable for it.
If you are building or redesigning the infrastructure behind an IoT platform, an MQTT-based service, or another sensitive product, Dropp Tempo can begin with an Architecture & Reliability Audit and continue through design, implementation, and ongoing operations.
Request an IoT Infrastructure Architecture & Reliability Review