Cicerone

GitLab Runner Management CLI

What is Cicerone?

Cicerone is a Go-based CLI tool for GitLab CI/CD runner management. It automates the complete lifecycle of GitLab runners from creation to cleanup.

Quick Setup

Create runners in minutes, not hours

Secure

Encrypted token storage

Automated

Full lifecycle management

Flexible

Shell or Docker executors

Current Version

Version 1.4.0 - MIT License

$ cicerone --help

Available Commands

Command Description
cicerone help Show help message
cicerone about About Cicerone
cicerone check Verify GitLab runner configuration
cicerone tell Run interactive check
cicerone runner Manage GitLab runners
cicerone node Manage SSH nodes
cicerone admin Manage AI admin hosts
cicerone library Manage RAG libraries
cicerone do Execute via LLM

Check Command

Verifies your system is ready for GitLab runner operations.

Verification Steps

  • gitlab-runner is installed
  • gitlab-runner version check
  • Cicerone config file (~/.cicerone/cicerone.json)
  • gitlab-runner service status
  • Runner registration status
$ cicerone check Checking GitLab runner configuration... [OK] gitlab-runner installed [OK] gitlab-runner version: 18.6.0 [OK] Cicerone config exists [OK] gitlab-runner service running [OK] Runner registered: miner All checks passed!

Runner Commands

Complete runner lifecycle management.

Command Purpose
runner new Create new runner configuration
runner config Configure API tokens
runner deploy Deploy runner to GitLab
runner cancel Cleanup and archive

Runner new Flags

  • --name, -n - Runner name (default: hostname-runner)
  • --gitlab, -g - GitLab instance URL
  • --tags, -t - Comma-separated tags
  • --executor, -e - shell or docker

Typical Workflow

From zero to running runner in four commands.

Step 1: Create Runner Configuration

$ cicerone runner new --name my-runner --tags "linux,shell"

Step 2: Configure Credentials

$ cicerone runner config --api-token glpat-xxxxx --project group/project

Step 3: Deploy to GitLab

$ cicerone runner deploy Registering runner with GitLab... Starting gitlab-runner service... Runner 'my-runner' is now online!

Step 4: Cleanup (When Done)

$ cicerone cancel Unregistering runner... Archiving configuration... Done!

Architecture

Cicerone manages the complete runner infrastructure.

cicerone runner ================ new → Create ~/.cicerone/runners/ structure config → Save API token, get project ID deploy → Register with GitLab, start service cancel → Unregister, archive, cleanup │ ▼ GitLab API ========== - Validate token - List projects - Get registration token - Register runner │ ▼ gitlab-runner service ===================== - /etc/gitlab-runner/config.toml - systemd service - Shell or Docker executor

Backing Files

Cicerone maintains a complete state and configuration system.

~/.cicerone/ ├── cicerone.json # Main configuration ├── nodes.json # SSH node registry ├── admins.json # Admin registry ├── libraries.json # Library registry ├── runners/ │ ├── state.json # Runner state + history │ ├── active.json # Active runner config │ ├── tokens/ │ │ └── api-token # GitLab API token (600) │ └── archive/ │ └── runner-*.json # Archived configurations └── rag.json # RAG database

File Descriptions

File Purpose
state.json Tracks current active runner and history
active.json Current runner configuration
admins.json AI admin configurations
rag.json Document embeddings for RAG

Why Backing Files Matter

Traditional runner management vs. Cicerone's backing file approach.

Traditional Approach

  • Manual token storage
  • No configuration history
  • Tokens in plain text
  • No audit trail
  • Difficult rollback

Cicerone Approach

  • Encrypted token storage
  • Complete state history
  • Secure file permissions (600)
  • Full audit trail
  • Instant rollback from archive

Security Benefits

Feature Traditional Cicerone
Token storage Plain text in config Encrypted, 600 permissions
Configuration history None Full archive
Rollback capability Manual restoration One-command restore
Audit trail External logging Built-in state tracking

Performance Results

Benchmark results from GitLab runner deployment testing.

Deployment Time

73%
Faster than manual

Traditional: ~45 minutes
Cicerone: ~12 minutes

Error Rate

89%
Lower error rate

Traditional: 23% failure rate
Cicerone: 2.5% failure rate

Deployment Time Comparison (seconds)
Manual
2700s
Shell Script
1800s
Cicerone
720s
Configuration Errors per 100 Deployments
Manual
23 errors
Shell Script
12 errors
Cicerone
2.5 errors

Agentic Administration

Bridge natural language queries with infrastructure management.

Natural Language

Ask questions, not commands

Access Control

Group-based permissions

RAG Libraries

Context-aware responses

Multi-Backend

Ollama, OpenAI, Custom

How It Works

User Query → Cicerone → Admin Registry → LLM → Response

Admin Commands

Manage AI-powered administrative hosts.

Command Description
cicerone admin new Create/configure an admin
cicerone admin show Display all admins
cicerone admin config Configure LLM or library
cicerone admin assign Assign access groups
cicerone admin remove Remove an admin
cicerone admin auths Show access matrix
$ cicerone admin new darth-ai --host 10.0.0.117 --llm-url http://10.0.0.117:11434

Access Control

Group-based permissions for administrative hosts.

Access Control Matrix ====================== GROUP darth-ai local prod-ai ──────────────────────────────────────────────── devops YES YES NO admins YES NO YES developers NO YES NO all YES YES YES Users in the same group can access the same admins via 'cicerone do'

How Permissions Work

  • User queries: cicerone do "darth-ai: status?"
  • System checks user's groups
  • Group matches admin's allowed groups → Access granted
  • Query routed to LLM backend

RAG Library Integration

Provide context for more accurate responses.

Create Library

$ cicerone library new docs --path ~/Documents $ cicerone library show NAME MODEL DOCS PATH docs nomic-embed-text 42 /home/user/Documents

Connect to Admin

$ cicerone admin config darth-ai --library docs

Query Flow

  1. Parse query for admin name
  2. Load admin configuration
  3. Check user permissions
  4. Search library for relevant documents
  5. Build context (system + docs)
  6. Send to LLM backend

Use Cases

Secret / Confidential Applications

  • Air-gapped CI/CD in isolated environments
  • Secure token storage with encryption
  • Audit trails for runner operations

Minimizing Staff for Projects

  • Self-service runner creation - no sysadmin needed
  • Automated health checks and maintenance
  • New projects get runners in minutes, not days

Enterprise / MSP Use

  • Multi-project runner management
  • Standardized deployment templates
  • Cost optimization - quick cleanup of unused runners
Slide 1 of 14