Self-hosting Apidog
  1. Maintenance & Upgrades
Self-hosting Apidog
  • Overview
  • Introduction
    • Obtaining Apidog On-Premises License
    • System Requirements
    • Data Privacy & Compliance
  • Deployment
    • Running Apidog on Docker
    • Running Apidog on Kubernetes
    • Running Apidog Multi-Container Deployment without Kubernetes
  • Post Deployment
    • Accessing Apidog Admin Panel
    • Accessing Apidog Web Interface
    • Installing Apidog On-Premises Client
  • Configurations
    • Environment Variables
    • Database Configuration
    • Storage Services Configuration
    • Git Connection Configuration
    • Authentication Providers
      • Using LDAP for Authentication
      • Using OKTA for Authentication
      • Using OAuth2.0 for Authentication
  • Maintenance & Upgrades
    • Updating Apidog
    • Backing up Apidog
    • License Renewal
    • System Design Flow
  • Troubleshooting
    • Troubleshooting
    • FAQ
  • Apidog API (coming soon)
  1. Maintenance & Upgrades

System Design Flow

The user authentication workflow begins at the client layer (either desktop or web client), which interfaces with the Single Sign-On (SSO) Service (e.g., Microsoft Entra ID) for identity verification. Upon successful authentication, users are directed through a secure edge gateway or firewall, enforcing perimeter security policies and ensuring encrypted traffic to the backend microservices. These backend systems, composed of internal APIs and data repositories, are responsible for executing the core business logic and supporting service delivery. Data is managed and transferred in a manner that guarantees confidentiality, integrity, and availability at every stage.

System Components#

1.
Internal Users: Users interact with the system through either the Desktop Client or the Web Client, both of which leverage modern front-end technologies that communicate with the backend services via a secure protocol.
2.
Gateway/Firewall: This security component functions as an intermediary layer, enforcing network security by inspecting inbound requests and ensuring that only validated and authenticated traffic reaches the backend infrastructure. It utilizes technologies such as TLS/SSL encryption, IP filtering, and access control policies to safeguard communication.
3.
Intranet/Cloud Service: Positioned as a routing layer, this component routes user requests to the appropriate backend services. It encapsulates the orchestration logic for distributing traffic.
4.
On-Premises Container: Deployed within an On-Premises Containerized Environment, these services are responsible for processing core application workflows. The backend services include:
API Service: This component handles all the core application logic, processing user requests and interacting with the database systems. It exposes endpoints that conform to API specifications and utilizes technologies such as JSON Web Tokens (JWT) for secure user session management.
Mock Service: A simulation layer utilized primarily for unit testing or integration testing, providing mock responses to mimic real-world API interactions in a controlled environment.
Docs Site Service: This service serves static content such as documentation. It queries backend data storage systems to efficiently retrieve the content.
5.
SSO Service: Authentication is facilitated by the SSO Service (e.g., Microsoft Entra ID), which supports OAuth 2.0, SAML, or OpenID Connect to authenticate users across multiple services with a single sign-on experience. This ensures centralized identity management and access control.
6.
Data Servers: Data persistence and caching are handled by:
MySQL: A relational ACID compliant database, responsible for storing structured relational datasets.
Redis: Provides an in-memory data store, used for caching frequently accessed data to reduce latency and improve the overall performance of the system.

Deployment and Scalability Considerations#

Apidog On-Premises is designed to scale across a distributed containerized environment, leveraging Docker or Kubernetes for orchestration. In this architecture, containers are stateless by design, ensuring that no local application state or user-specific data is stored within the containers themselves. Instead, all state is managed through shared, centralized services such as Redis for session data or a relational database for transactional data.
This design pattern guarantees elastic scalability, enabling seamless load balancing across containers using strategies like round-robin, least connections, or IP hash. These mechanisms ensure high availability, fault tolerance, and horizontal scalability for optimal service delivery.

Advanced Features#

Security: All communication between components is secured using TLS for encryption, ensuring that sensitive data is protected in transit. Additionally, security headers such as X-Content-Type-Options and Strict-Transport-Security (HSTS) are enforced to mitigate common web security vulnerabilities.
Error Handling: The system implements global exception handling via centralized error management in the backend services. This ensures that any failures in communication or business logic are caught, logged, and handled gracefully, with appropriate fallback mechanisms or error messages returned to the client.

Data Flow Diagram#

apidog-diagram-20250707-123326.jpeg

Sequence Diagram#

Modified at 2025-12-08 05:11:41
Previous
License Renewal
Next
Troubleshooting
Built with