Overview

This documentation focuses on the on-premise deployment of Nected, designed for teams that require full control over their data, infrastructure, and execution environment. Whether you're operating in a regulated industry, managing customer-facing applications with strict latency SLAs, or simply avoiding third-party dependencies, deploying Nected on your own infrastructure gives you the flexibility and control to meet these demands.

Nected's on-premise architecture is modular, resilient, and built to integrate seamlessly into your existing systems. It combines a low-code rule-building frontend with a scalable backend powered by Temporal and containerized microservices. The platform supports deployment via:

• Docker Compose for quick local setups

• Kubernetes with Helm for scalable, production-grade environments

This documentation provides a comprehensive walkthrough of both deployment strategies, backed by detailed infrastructure requirements, version compatibility, and configuration guidelines.

Core Architecture

Nected's architecture is fundamentally designed to optimize task execution in a no-code/low-code environment. This section breaks down the platform's key components, offering a clear view of how each contributes to overall performance and scalability.

The architecture of Nected is structured to efficiently manage and execute backend logic flows. It comprises several critical services, each playing a unique role in the system:

1. Overall Architecture:

• Fundamental Approach: Nected adopts a task-oriented approach where backend logic flows, created through the Nected console, are executed as a chain of tasks. These tasks, ranging from simple CRUD operations to complex user segmentations, can be executed independently by any worker within the system.

• Execution Engine: At the core of Nected is its execution engine, responsible for carrying out the backend logic flows at scale. This engine is pivotal in ensuring the platform's scalability and high-performance capabilities.

2. Core Components:

• Router Service:

  • Functionality: This lightweight GoLang service handles API / webhook triggers for backend logic flows. It is responsible for validating requests, applying throttling, and authenticating incoming requests. Upon validation, it triggers execution using a temporal framework and response.

  • Accessibility: The Router Service is the entry point to the cluster, with all other services being internal. It is the only service that can be accessible through Load Balancer / API Gateway from the outside network.

• Task Manager:

  • Technology: We have used Temporal, an open-source durable execution framework, to manage tasks and task queues.

  • Role: The Task Manager interfaces with a Temporal cluster, which uses Postgres[ Cassandra for high scaling] as a persistent store, facilitating efficient task execution and management.

• Executor Service:

  • Functionality: Another lightweight GoLang service, the Executor Service is responsible for fetching and executing tasks. It independently scales to maintain high scalability and is tasked with executing the backend logic for both rules and workflows.

  • Scalability: Configured to scale as required, it contributes to the overall flexibility and adaptability of the Nected platform.

3. Deployment and Fault Tolerance:

• Deployment on Kubernetes: All services within Nected are deployed on a Kubernetes cluster. This choice of infrastructure underlines the platform's emphasis on scalability and reliability.

• Fault Tolerance: Each service is designed to be fault-tolerant, ensuring the platform's resilience and uninterrupted operation.

4. Performance Benchmarking Setup:

• Objective: The aim was to benchmark a Kubernetes cluster capable of handling ~300rps throughput with specific Cassandra configurations.

• Configuration Details: The Router Service was configured with a minimum of 2 and a maximum of 8 pods, each provisioned with 200m CPU and 512MB memory.

Detailed load testing and performance metrics can be found in our performance benchmarking blog.

In conclusion, the Nected platform’s architecture is a well-orchestrated system of services, each optimized for performance and scalability. This architecture not only enables efficient execution of backend logic flows but also ensures high availability and resilience, making Nected a reliable solution for various no-code/low-code backend applications.

Current Tech Stack Versions:

The following table details the specific versions of the technology stack we’re currently on. So these specific versions are required for the On-Premise deployment of Nected:

Category	Technology	Version
Platform Language & Compiler	React	~18.2
	NodeJS	Latest LTS
	Golang	~≥ 1.19
	Python	~≥ 3.11
Database and Storage	PostgreSQL	~≥ 9.6
	Elasticsearch	7 or 8
	Redis	Latest LTS
Infrastructure, Packaging, and Distribution	Docker	v25
	Kubernetes	≥ 1.24
	Helm	v3

These versions are critical to ensure compatibility and optimal performance of the Nected On-Premise deployment. It is recommended to adhere to these versions specifically, as they provide the necessary features and stability required for a successful installation.

Deployment Modes

Nected offers two supported deployment strategies for on-premise environments. Each serves a different operational requirement:

Mode	Description	When to Use	Notes
Docker Deployment	Runs all Nected components via Docker Compose on a single host.	Development, testing, PoC	Fast setup, not production-grade, no multi-node support
Kubernetes Deployment	Uses Helm charts to deploy Nected on a Kubernetes cluster.	Production, staging, distributed workloads	Scalable, fault-tolerant, supports autoscaling

For most teams, local deployment works well during evaluation. For production or high-load environments, Helm-based deployment on Kubernetes is strongly recommended. Both methods are fully documented with step-by-step setup guides.

Supported Cloud Solutions

Page References

For more detailed instructions and information, please refer to the following pages in the on-premise deployment documentation: