Horus by Fidumtec

Architecture

A single scalable multi-tenant Core, with hybrid architecture and experiences adapted to each operating mode.

Architecture

Distributed architecture for cameras, community, IoT, and AI

Horus is organized as a distributed service architecture: cameras and sensors remain at each site, the mobile experience enables operation from anywhere, edge can run workloads close to the capture point, and the cloud environment coordinates identities, permissions, notifications, scenarios, and integrations.

Each Horus instance represents an autonomous environment. Relationships between devices, users, groups, calendars, permissions, and automations exist inside that instance, ensuring operational independence and logical security between different installations or customers.

Horus hybrid and distributed architecture

Connected layers of the ecosystem

Horus by Fidumtec is more than an app, an IoT solution, or a camera system. It is a distributed platform made of connected layers:

  1. Field: cameras, sensors, actuators, physical devices, and installed infrastructure.
  2. Gateway / local edge: gateways, adapters, field protocols, and processing close to the site.
  3. ISP / operator edge: ISP network, datacenter, regional edge, storage, GPU, recording, and inference.
  4. Horus Cloud: identity, instances, users, permissions, rules, dashboards, events, and multi-tenancy.
  5. AI and automation: video analytics, intelligent events, rules, scenarios, and automatic or assisted actions.
  6. Mobile experience / Clipxu: visualization, alerts, field operation, and user interaction.

Points 4, 5, and 6 allow the centralized logic of the architecture to coexist in distributed form across multiple platforms. Horus Cloud is no longer understood as a single cloud; it operates as a network of clouds, including pure cloud nodes, operator clouds, and connected ISP deployments.

Instance-based connection and multi-cloud operation

Each Horus instance belongs to a specific cloud node. That node can be associated with an ISP, a specific cloud region, or a cloud operated within a distributed architecture. The connection is not resolved against one global cloud, but against the cloud node where the instance being operated lives.

In the Clipxu mobile application, the user connects to the cloud node where the Horus instance being configured or operated is registered. If the user switches instances, the active configuration starts pointing to the cloud node corresponding to that new instance.

In a dashboard, the behavior is different: each monitor can represent the visualization or control of a different Horus element. For that reason, dashboard connections are made against the cloud node that owns the Horus instance of each monitored element. A single dashboard can operate, in parallel, elements hosted in ISP clouds, cloud regions, or different cloud nodes.

Multi-cloud routing by Horus instance

Vision: one technology platform

Backend capacity is not defined by the size of an interface or by the number of cameras a typical user manages. Horus was conceived as a multi-tenant platform where each instance preserves its autonomy, users, permissions, devices, and rules, while horizontal processing grows with the available computing capacity.

The same Core can support one camera, a community, a multi-site enterprise, or thousands of instances operating in parallel. There are no “small” and “large” backends: there is one shared platform that distributes workloads, keeps environments isolated, and expands resources without fragmenting the architecture.

Hybrid architecture that accelerates business

Simplicity is an experience decision

Horus hides technical complexity so onboarding and daily operation remain simple. Device discovery, configuration assistants, automations, and direct navigation are product decisions; they are not Core limitations.

When an operation grows from dozens to thousands of cameras, the working model must evolve. An enterprise operation or monitoring center needs advanced search, complex filters, bulk actions, hierarchies, operational dashboards, corporate permissions, auditing, and management by site, region, or branch.

The difference is not processing capacity. What changes is:

  • The interface presented to the user.
  • The tools made available.
  • Configuration, supervision, and response workflows.
  • The level of aggregation and operational governance.

Operating modes and scope

ModeExperience goal
PersonalAbsolute simplicity for a focused environment.
CommunityCollaborative management of spaces, neighbors, permissions, and events.
EnterpriseHierarchical, multi-site operation with bulk administration tools.
Analytics and AIExploration of large volumes of events, metrics, and operational data.
Monitoring centerReal-time supervision, incident prioritization, and coordinated response.

Every mode uses the same backend. A specialized experience can evolve without duplicating services, artificially separating data, or creating a parallel platform.

One platform and different user experiences

Hybrid architecture: process where it adds the most value

Cameras remain at the customer site and connect securely to the service infrastructure. Depending on the requirement, modules can run at the local edge, in an intermediate environment with low latency and available bandwidth, or in the cloud. This flexibility balances latency, traffic, cost, availability, and governance.

Streaming is protected from the gateway through the access layer. Specialized processes consume authorized video and turn images into events or data; the Core coordinates rules, notifications, scenarios, and history, while the mobile experience consumes information regardless of where it was produced.

Horus streaming processing strategy

One Core, different ecosystem expressions

The Horus “flavors” are not incompatible backends. They are different ways to use the same technology core:

  • Horus brings together intelligent communities, cameras, IoT, permissions, and automation.
  • HorusSense focuses the platform on analytics, AI, and business intelligence.
  • Clipxu provides the mobile experience for visualization, alerts, and operation.
  • Fidumtec integrates and institutionally supports the ecosystem and its verticals.

This separation adapts the commercial proposition and experience without fragmenting backend development. The Core remains unique; each expression selects the capabilities, interfaces, and workflows suited to its context.

Relationship between Fidumtec, Horus, Clipxu, and HorusSense

1. Cameras and sites

  • Cameras are onboarded using standards such as ONVIF.
  • A single user can operate owned cameras or views shared by third parties.
  • The platform avoids depending on each manufacturer's proprietary cloud.

2. Cloud, edge, and mobile experience

  • Manages users, groups, cameras, permissions, and communities.
  • Defines 24/7 access windows or temporary permissions with start and end dates.
  • Coordinates specific notifications for linked users.
  • Maintains personalized dashboards according to each user's permissions.
  • Allows Clipxu to act as the mobile experience for visualization, alerts, and operation.
  • Provides the foundation for deployments such as ISP, IoT, communities, and critical infrastructure.

3. Sensors, actions, and AI

  • Integrates selected IoT sensors to complement camera information.
  • Can execute remote physical actions using IoT devices.
  • Processes video images with inference engines to generate events and information for the user.
  • Enables rules based on events, logical conditions, sensor states, schedules, calendars, and user presence.

4. Deployments