Project Tick – Platform Transition Notice

Published on February 22, 2026

Project Tick has updated its platform strategy in line with its long-term sustainability and infrastructure sovereignty goals.

This document formally defines the transition from a GitHub-centric model to a GitLab SaaS-centric model and establishes the hybrid CI architecture.

  1. Strategic Framework

Project Tick's core principles are: • Not being dependent on a single commercial provider • Keeping code, CI, and artifact production under control • Optimizing costs and scale based on data

The platform choice is an operational decision, not an ideological one.

  1. GitLab SaaS Positioning

Project Tick has positioned GitLab SaaS as its primary development platform.

This decision is based on the following factors: • Our application to the GitLab OSS Ultimate SaaS Program has been approved. • A monthly limit of 50,000 CI minutes has been secured. • Merge Request-based workflows are implemented on GitLab. • A small-scale, controllable self-managed GitLab Runner has been prepared.

GitLab is positioned as the canonical repository and MR management center.

However, the CI architecture is intentionally not confined to a single platform.

  1. CI Architecture

The transition is not a “complete transition to GitLab CI”. The model is hybrid.

3.1 Merge Request and Push Pipelines • Push and MR pipelines run on GitHub Actions in the dedicated branches of specific repositories. • This design is deliberate and performance-oriented. • GitHub Actions has not been disabled.

3.2 Runner Architecture and Architectural Constraints • Our self-managed runners are based on the amd64 architecture. • ARM64 workloads are executed either on GitLab hosted runners or on GitHub Actions, depending on capacity distribution and architectural constraints.

The reason for this distribution: • Architectural compatibility • Preventing CI bottlenecks • Preventing capacity congestion in a single runner pool

  1. Shadow Runner Bridge Structure

A CI bridge layer named “Shadow Runner” has been implemented to orchestrate cross-platform workload execution.

This structure: • GitLab-centric repository management • Execution of selected workloads on GitHub Actions • Balancing runner capacity

In repositories with ProjT Launcher and high CI load, some tasks: • are executed on GitHub Actions. • Workflows related to project-tick-portal-private-modules are executed via a dedicated runner repository to distribute CI load.

This decision is not related to code visibility or access level, but strictly to runner capacity management and workload balancing.

Workload distribution is driven by repository size and CI load intensity. The goal is capacity optimization, not isolation.

  1. Mirror Policy

New approach: • GitHub is not the primary development platform. • Canonical source code is on GitLab SaaS. • GitHub mirroring is not mandatory for small and medium-sized repositories. • Limited mirroring may be applied to large or CI-advantageous repositories.

GitHub is used as a strategic compute and workload execution layer; it is not a central management point.

  1. Infrastructure Sovereignty

Reminder: • All repositories are backed up on our own servers. • Independent backup infrastructure is active. • In case of operational risk originating from GitHub or GitLab, a full migration scenario is ready.

Project Tick infrastructure is designed to be platform-independent.

  1. Conclusion

Project Tick: • Positions GitLab SaaS as the main development center. • Implements a hybrid CI architecture. • Consciously distributes AMD64 and ARM64 workloads. • Manages runner capacity risk in advance. • Leverages the OSS program benefits in an operationally optimized manner.

This transition remains ongoing. CI deployment and load balancing will be progressively improved.

Thank you to our community and everyone who contributed.

— Project Tick Governance

← Back to News