flxbl docs
slackGitHub
  • flxbl
  • sfp
  • sfops
  • Overview
  • Getting Started
    • Pre-Requisites
    • Install sfp
    • Configure Your Project
    • Build & Install an Artifact
    • Congratulations!
    • Docker Images
      • sfp-pro
  • CONCEPTS
    • Overview
    • SF CLI vs. SFP
    • Domains
    • Packages
    • Supported package types
      • Unlocked Packages
      • Org-Dependent Unlocked Packages
      • Source Packages
      • Diff Package
      • Data Packages
    • Artifacts
    • Package vs Artifacts
    • Identifying types of a package
    • Dependency management
    • Transitive Dependency Resolution
    • Destructive Changes
  • configuring a project
    • Project structure
    • Setup Salesforce Org
    • Creating a package
    • Defining a domain
    • Release Config
  • BUILDING ARTIFACTS
    • Overview
    • Determining whether an artifact need to be built
    • Building a domain
    • Building an artifact for package individually
    • Limiting artifacts to be built
    • Controlling aspects of the build command
      • Ignoring packages from being built
      • Building a collection of packages together
      • Selective ignoring of components from being built
      • Use of multiple config file in build command
    • Configuring installation behaviour of a package
      • Always deploy a package
      • Skip Install on Certain Orgs
      • Optimized Installation
      • Pre/Post Deployment Script
      • Reconciling Profiles
      • PermissionSet Assignment
      • Updating Picklist
      • Entitlement Deployment Helper
      • Field History & Feed Tracking
      • Aliasfy Packages
        • Aliasfy Packages - Merge Mode
      • State management for Flows
  • Installing an artifact
    • Overview
    • Controlling Aspects of Installation
    • Applying attributes of an artifact
    • BuiltIn Deployment Helpers
      • PermissionSet Group Awaiter
  • publishing and fetching artifacts
    • Publish Artifact
    • Fetching Artifacts
  • Releasing artifacts
    • Overview
    • Release Definitions
    • Generating a release definition
    • Generating a changelog
  • Validating a change
    • Overview
    • Different types of validation
    • Limiting Validation by Domain
    • Controlling validation attributes of a package
      • Skip Testing
      • Skip Coverage Validation
      • Test Synchronously
  • Analysing a Project
    • Overview
    • Duplicate Check
  • Environment Management
    • Pools
      • Scratch Org Pools
        • Defining a pool
        • Setting up your Salesforce Org for Scratch Org Pools
        • Pool Operations
          • Preparing pools
            • Handling dependencies
          • List Scratch Orgs in a pool
          • Fetch a scratch org
          • Delete Pools
      • Sandbox Pools
        • Sandbox Pool Initialization
        • Fetch a Sandbox from Pool
        • Monitor Sandbox Pools
    • Review Environments
      • Commands
        • Fetch a Review Environment
        • Check Review Environment Status
        • Extend a Review Environment
        • Transition Review Environment Status
        • Unassign a Review Environment
      • Considerations
    • Sandbox
      • Create Sandbox
      • Delete Sandbox
      • List Sandbox
      • Login to Sandbox
      • Update Sandbox
  • Development
    • Development Environment
    • Pull Changes from your org
    • Push Changes to your org
    • Dependency Management
      • Expand Dependencies
      • Shrink Dependencies
      • Explain Dependencies
  • Running sfp as a server
    • Introduction
    • sfp-pro-server: Architecture Overview (Alpha)
      • Task Processing System
      • Authentication & Security Architecture
      • Authentication System: Deep Dive
      • Database Architecture
      • Network Architecture and Integration System
      • Integration Architecture: Building Extensions
    • Installing SFP Server
    • Initializing SFP server
  • API Reference
    • Health
    • Authentication
    • Token
    • Salesforce
    • Team
    • Users
    • Tasks
    • Key Value
    • Repository
    • WebHooks
  • Metrics
    • Available Metrics
    • Custom Metrics
    • Configuring Collectors
      • Datadog
      • Splunk
      • New Relic
      • StatsD
  • Helpers
    • Managing Shared Resources
  • Command Guide
    • Core
      • Build
      • Quickbuild
      • Publish
      • Install
      • Release
    • Advanced
      • Validate
      • Artifacts
      • Changelog
      • Impact
      • Pool
      • Metrics
      • Repo
    • Utilities
      • Apex Tests
      • Flow
      • Dependency
      • Profile
  • FAQs
    • Common Errors
      • Org Shapes
      • Troubleshooting Unlocked Packages Build Failure Due to Code Coverage
    • Common Questions
      • Email Templates Deployment: Classic vs Lightning
      • Dealing with Long Build Times in Salesforce
      • Standard ValueSets and unlocked packages
      • Common Issues encountered with aliasfied packages
      • API Version
      • Understanding alwaysDeploy and skipIfAlreadyInstalled in Deployment Pipelines
    • sfp versioning and upgrade Process
  • References
  • Legal
    • Terms of Service for sfp
    • Terms of Service for 'sfp-pro' Software
  • LLMs.txt
Powered by GitBook
On this page
  • Understanding Network Design
  • Edge Layer: The Role of Caddy
  • Integration Architecture
  1. Running sfp as a server
  2. sfp-pro-server: Architecture Overview (Alpha)

Network Architecture and Integration System

Last updated 3 months ago

Understanding Network Design

The network architecture of sfp pro server addresses a fundamental challenge in Salesforce DevOps: How do we securely connect various clients and systems to Salesforce while maintaining strict security boundaries and ensuring efficient operations? This challenge becomes even more complex when we consider that the system must handle multiple types of connections simultaneously - from CLI tools, CI/CD systems, webhooks, and long-running deployment operations.

Edge Layer: The Role of Caddy

At the entry point of every sfp pro server instance sits Caddy, serving as both a reverse proxy and security gateway. Think of Caddy as the system's front door - it's where all external connections first arrive and are properly routed to their destinations.

Caddy performs several crucial functions that form our first line of defense:

First, it handles all TLS termination, managing certificates automatically whether in FLXBL-managed or self-hosted environments. This ensures all communications are encrypted using modern TLS protocols and cipher suites.

Second, it provides intelligent request routing. When a request arrives, Caddy determines whether it should go to the API service, the WebSocket server for real-time updates, or be handled as a webhook. This routing happens based on the request type and path, ensuring each request reaches the appropriate service.

Third, it implements our first layer of security controls, including rate limiting, basic DDoS protection, and HTTP header standardization. These protections help ensure system stability and security before requests even reach our application layer.

Integration Architecture

The integration system in sfp pro server needs to handle several distinct types of communication patterns. Let's examine how these work together:

Secure Salesforce Integration

The most critical integration point in our system is with Salesforce organizations. When a task needs to interact with Salesforce, whether for a deployment, metadata retrieval, or org validation, the system follows a carefully orchestrated process:

This process ensures complete security of Salesforce credentials through several key mechanisms:

First, credentials are never stored in the application layer. Instead, they're securely stored in our secret management system and only accessed when needed for specific operations.

Second, when a worker needs to connect to Salesforce, it receives just-in-time credentials that exist only in memory. These credentials are immediately cleared when the operation completes, and the worker process terminates.

Third, each operation gets its own isolated worker process, ensuring that credential access is completely separated between different operations and organizations.

Webhook Management

The webhook system handles incoming events from various sources, including Salesforce platform events, GitHub/GitLab notifications, and CI/CD system callbacks. Here's how this process works:

When a webhook arrives:

  1. Caddy performs initial validation and TLS termination

  2. The webhook handler verifies the source's signature

  3. The system maps the event to appropriate tasks

  4. Tasks are created with appropriate priorities

Real-time Updates

The system provides real-time visibility into operations through a WebSocket-based update system. This enables clients to monitor long-running operations, receive immediate status updates, and track resource utilization in real-time.

The WebSocket connections are managed through the same secure edge layer, ensuring consistent security policies and access controls: