Skip to content

Hybrid Appcircle Deployments: Anadolu Sigorta, TOGG & Tüpraş

This page documents hybrid deployment patterns where Appcircle components and customer dependencies are hosted on different infrastructures and require controlled network connectivity (VPN, allowlists, or a proxy bridge).

Scope: High-level topology, connectivity, access prerequisites, and operational notes for three customer setups.

Why “hybrid” matters in Appcircle

Appcircle can be operated with different deployment models:

  • Self-hosted Server (Docker / Podman) in the customer’s preferred environment
  • Appcircle Cloud Server (SaaS)
  • Self-hosted Runner(s) (customer DC / vendor DC / public cloud)
  • Appcircle Cloud Runner(s) (SaaS runner)

In hybrid models, components and dependencies may live on different providers or networks. This changes:

  • network routing (VPN, allowlists, proxy bridges)
  • access to customer dependencies (Git providers, registries, internal services)
  • operational responsibilities (backups, snapshots, monitoring, ownership boundaries)

Comparison summary

Customer Server Location Server Type Runner Location Runner Type Connectivity pattern Backup / Snapshot
Anadolu Sigorta GCP (anadolu-sigorta-appcircle-server) Docker self-hosted Teknotel Self-hosted Runner ↔ Anadolu resources via VPN Snapshot every 14 days
TOGG Appcircle Cloud SaaS Teknotel Self-hosted Runner ↔ TOGG resources via VPN N/A (server side is SaaS)
Tüpraş Appcircle Cloud SaaS Appcircle Cloud SaaS runner Cloud ↔ Teknotel Reverse Proxy (public) ↔ Tüpraş internal Azure DevOps N/A (server/runner are SaaS)

Anadolu Sigorta

Topology

  • Appcircle Server is hosted on Google Cloud (GCP)

  • Instance/host: anadolu-sigorta-appcircle-server

  • Deployment model: Docker (self-hosted)
  • Runner is hosted in Teknotel
  • Anadolu internal resources are reachable only over VPN

Connectivity model

  • Runner requires VPN connectivity to Anadolu network resources.
  • Any Anadolu service/resource that Appcircle interacts with is reached through VPN.
  • To enable Runner access, Runner public egress IP must be added/allowlisted on the Anadolu VPN side.

Important: Keep an explicit record of the allowlisted Runner egress IP(s) and the date the VPN configuration was applied.

Operational notes

  • Backups / Snapshots

  • Anadolu Sigorta server host is snapshotted every 14 days.

  • Ensure snapshot coverage includes:

    • Appcircle persistent data volumes
    • configuration files / env files
    • certificates / secrets (if stored on disk)

  • Access

  • VPN allowlisting is required for Runner.

  • Maintain a change log:

    • When Runner egress IP changed
    • When VPN config updated
    • Validation steps performed

TOGG

Topology

  • Appcircle Server is Appcircle Cloud (SaaS)
  • Runner is hosted in Teknotel
  • Runner has VPN connectivity to TOGG environment

Connectivity model

  • Runner ↔ TOGG resources communicate over VPN.
  • Server (SaaS) controls orchestration and job scheduling; Runner performs builds inside Teknotel and reaches TOGG dependencies via VPN.

Operational notes

  • Backups / Snapshots

  • Server-side backups are handled by the SaaS platform.

  • Runner-side responsibilities remain:

    • Runner host maintenance
    • VPN uptime and routing
    • any local caching/artifact storage if used

Tüpraş

Context / constraint

  • Tüpraş uses Azure DevOps as the Git provider.
  • Their Azure DevOps endpoint is not externally accessible (internal-only).
  • Appcircle Cloud Server and Cloud Runner cannot directly reach that internal Git provider.

Solution approach

To bridge connectivity securely, a Reverse Proxy is planned/hosted in Teknotel Data Center:

  • The reverse proxy has a public endpoint (reachable by Appcircle Cloud Server and Cloud Runner).
  • The reverse proxy can reach Tüpraş internal resources.
  • The reverse proxy’s IP is allowlisted on the Tüpraş side so it can access the internal Azure DevOps.

This allows Appcircle (SaaS) to interact with an internal-only dependency without exposing the dependency directly to the internet.

Topology

  • Appcircle Server: Appcircle Cloud (SaaS)
  • Runner: Appcircle Cloud Runner (SaaS)
  • Connectivity bridge: Teknotel Reverse Proxy (public)
  • Internal dependency: Tüpraş Azure DevOps (internal-only)

Connectivity model

  • Appcircle Cloud Server/Runner → Public Reverse Proxy (Teknotel)
  • Reverse Proxy → Internal Azure DevOps (Tüpraş)

Key requirement: Reverse Proxy public IP must be stable and explicitly allowlisted for access to internal Azure DevOps.

Operational notes

  • Reverse proxy ownership

  • Define who owns:

    • TLS certificate lifecycle
    • proxy configuration changes
    • availability/monitoring
    • access logs and audit trails

  • Security controls

  • Limit exposure to only required paths/hosts (Azure DevOps endpoints).

  • Apply authentication/authorization controls if supported/required.

  • Enable logging and rate limiting where appropriate.

  • Change management

  • Any reverse proxy IP or DNS change requires:

    • updating the Tüpraş allowlist
    • re-validating repo access from Appcircle

Common operational guidance for hybrid setups

1) Define “what runs where”

  • Server: orchestration, UI, API, scheduling
  • Runner: build execution, signing, environment tooling

Hybrid changes are mostly about:

  • network paths to customer dependencies (repos, registries, internal services)
  • reliable identity and access (VPN, allowlists, proxy bridges)

2) Keep allowlists stable

  • Prefer static IP for:

  • Runner egress (self-hosted runner cases)

  • Proxy egress/public endpoints (proxy bridge cases)

  • Runbook step (always):

  • When allowlisted IP changes → update allowlist → re-validate access

3) Minimum validation for any change

After changes (VPN, routes, firewall, runner upgrades, proxy updates):

  • Runner registers and stays online
  • A test pipeline can fetch dependencies (Git/ADO/registry) through the expected network path
  • Artifact upload/download works (where applicable)
  • Signing steps (if used) succeed

Architecture diagram

topology