depot-github-runners

bởi posthog

Cấu hình các runner GitHub Actions do Depot quản lý để thay thế trực tiếp cho các runner do GitHub lưu trữ. Sử dụng khi thiết lập hoặc di chuyển các quy trình làm việc GitHub Actions…

npx skills add https://github.com/posthog/posthog-foss --skill depot-github-runners

Depot GitHub Actions Runners

Depot provides managed, ephemeral, single-tenant GitHub Actions runners. Drop-in replacement for GitHub-hosted runners — change the runs-on label and everything else stays the same.

Requirement: Repository must be owned by a GitHub organization (not a personal account).

Depot runners are not Depot CI

Depot runners keep GitHub Actions as the engine, so the workflow lives in .github/workflows/ and the checks still come from the github-actions app. Depot CI is a different product: it reads .depot/workflows/, which GitHub Actions ignores, and posts its own check runs from the depot-code-access app. Use the depot-ci skill for that one.

Its references/posthog-check-run-semantics.md compares what each engine reports for a skipped, empty-matrix or continue-on-error job, and how GitHub and the Trunk merge queue score those conclusions.

Setup

  1. Depot dashboard → GitHub Actions → Connect to GitHub → Install Depot GitHub App
  2. For public repos: GitHub org settings → Actions → Runner groups → Default → "Allow public repositories"
  3. Update runs-on in your workflow files

Org Context Check for Multi-Org Users

If a user belongs to multiple organizations and expected repos/settings/runners are not visible, verify Depot org context first:

depot org show              # Current org ID
depot org list              # Orgs the user belongs to
depot org switch <org-id>   # Optional: set default org

For commands that support it, pass --org <org-id> to target the org where the workflow/repo lives.

Runner Labels

Use a single label. Format: depot-{os}-{version}[-{arch}][-{size}]

Ubuntu (x86, AMD)

LabelCPUsRAMDisk$/minMinutes multiplier
depot-ubuntu-24.0428 GB100 GB$0.0041x
depot-ubuntu-24.04-4416 GB130 GB$0.0082x
depot-ubuntu-24.04-8832 GB150 GB$0.0164x
depot-ubuntu-24.04-161664 GB180 GB$0.0328x
depot-ubuntu-24.04-3232128 GB200 GB$0.06416x
depot-ubuntu-24.04-6464256 GB250 GB$0.12832x

The minutes multiplier is the billing driver: billed minutes = elapsed minutes × multiplier, so larger runners consume your included minutes faster.

Ubuntu 22.04 also available: depot-ubuntu-22.04, depot-ubuntu-22.04-4, etc.

Ubuntu (ARM — Graviton4)

Same sizes and pricing as Intel. Add -arm suffix: depot-ubuntu-24.04-arm, depot-ubuntu-24.04-arm-4, depot-ubuntu-24.04-arm-8, etc.

Windows Server

LabelCPUsRAM$/minMinutes multiplier
depot-windows-202528 GB$0.0082x
depot-windows-2025-4416 GB$0.0164x
depot-windows-2025-8 through -648–6432–256 GB$0.032–$0.2568x–64x

Windows Server 2022 also available: depot-windows-2022, etc. Windows limitation: No Hyper-V (AWS EC2 limitation), so Docker workloads that require it are unlikely to work.

macOS (Apple M2 on macOS 14/15, M4 on macOS 26)

LabelCPUsRAMDisk$/min
depot-macos-26824 GB400 GB$0.08
depot-macos-15 / depot-macos-latest824 GB400 GB$0.08
depot-macos-14824 GB400 GB$0.08

macOS is NOT fully elastic — fixed pool with FIFO queuing.

Aliases

depot-ubuntu-latest → Ubuntu 24.04, depot-windows-latest → Windows 2025, depot-macos-latest → macOS 15

Migration Example

jobs:
  build:
    # Before:
    # runs-on: ubuntu-latest
    # After:
    runs-on: depot-ubuntu-24.04-4
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

Common Mistakes

# ❌ WRONG — multiple labels cause stability issues
runs-on: [self-hosted, depot-ubuntu-24.04]

# ✅ CORRECT — always use a single Depot runner label
runs-on: depot-ubuntu-24.04-4

Caching

Actions using the GitHub Actions cache API automatically use Depot Cache — no config changes needed. This includes actions/cache, actions/setup-node, actions/setup-python, actions/setup-java, and any action using @actions/cache.

Pre-configured build tool caches (zero config on Depot runners):

ToolWhat's pre-configured
TurborepoTURBO_API env var set — just run turbo build
Bazel~/.bazelrc pre-populated — just run bazel build //...
sccacheSCCACHE_WEBDAV_ENDPOINT set — use RUSTC_WRAPPER: 'sccache'
Mavensettings.xml pre-populated (cache id depot-cache)
Pantspants.toml pre-configured — just run pants package ::
moonrepoEnv vars set — just run moon run build

Cache behavior: repository-scoped, no branch isolation, encrypted, up to 1000 MiB/s throughput, configurable retention (7/14/30 days).

To disable auto-cache: org settings → turn off "Allow Actions jobs to automatically connect to Depot Cache."

Dagger Integration

Deprecated: Dagger Engine support on Depot GitHub Actions Runners is being deprecated and will be removed in a future update. Don't recommend this integration for new workflows.

runs-on: depot-ubuntu-latest,dagger=0.18.4

Launches a dedicated Dagger Engine VM with persistent NVMe cache. Dagger CLI pre-installed. Additional $0.04/min.

Egress Filtering (Linux Only)

Configure in org settings → GitHub Actions Runners → Egress Rules. Set default rule to Allow or Deny, then add specific allow/deny rules for IPs, CIDRs, or hostnames. Deny rules take precedence over Allow rules. Loopback traffic (127.0.0.1, ::1) is always allowed, and Depot auto-allowlists depot.dev domains, GitHub Actions service IPs, and AWS service IPs. Hostnames in rules are resolved and pinned in /etc/hosts. Container builds with depot build work with egress filtering enabled — Depot adds BuildKit machine IPs to the allowlist as they're allocated. Not supported on macOS or Windows. Incompatible with Tailscale.

Access Private Endpoints with Tailscale

Use Tailscale when jobs need to reach private services (internal APIs, databases, private subnets) without static IP allowlists.

How it works on Depot:

  • Depot GitHub Actions runners join your tailnet as ephemeral nodes at job start.
  • Access is controlled with your Tailscale ACLs (recommended tag: tag:depot-runner).
  • No workflow YAML changes are required just to connect runners to private endpoints.

Setup:

  1. In Tailscale ACLs, create a runner tag (for example tag:depot-runner) under tagOwners.
  2. Create a Tailscale OAuth client with Keys > Auth Keys write scope and choose that tag.
  3. In Depot org settings, open Tailscale settings and connect using the OAuth client ID/secret.
  4. Add ACLs allowing tag:depot-runner to access target hosts/subnets.

ACL examples:

{
  "acls": [
    {
      "action": "accept",
      "src": ["tag:depot-runner"],
      "dst": ["database-hostname"]
    }
  ]
}
{
  "acls": [
    {
      "action": "accept",
      "src": ["tag:depot-runner"],
      "dst": ["192.0.2.0/24:*"]
    }
  ]
}

Reference docs:

Dependabot

Enable "Dependabot on self-hosted runners" in GitHub org settings. Jobs auto-run on depot-ubuntu-latest.

Important: OIDC is not supported for Dependabot. Use token: input with a DEPOT_TOKEN secret instead.

SSH Debugging

steps:
  - uses: actions/checkout@v4
  - uses: mxschmitt/action-tmate@v3
  - run: npm test

Troubleshooting

ErrorFix
"No space left on device"OS uses ~70 GB disk; upgrade to larger runner or clean disk in workflow
"Failed to open the device 'kvm'" / "Could not access KVM kernel module"Runners don't provide /dev/kvm; move KVM/QEMU/Android-emulator jobs to Depot CI, where nested virtualization is enabled by default
"Lost communication with server"Check status.depot.dev; check org usage caps
"Operation was canceled"Manual cancel, concurrency cancel-in-progress, or OOM — check memory in dashboard
"Unable to get ACTIONS_ID_TOKEN_REQUEST_URL"Dependabot doesn't support OIDC — use DEPOT_TOKEN secret
Workflows not startingVerify single runner label; check runner group allows the repo; verify Depot GitHub App permissions
Stuck workflowsForce cancel via GitHub API: POST /repos/{owner}/{repo}/actions/runs/{id}/force-cancel

Thêm skills từ posthog

error-tracking-hono
posthog
Theo dõi lỗi PostHog cho Hono
tuning-incremental-sync-config
posthog
Cấu hình của một đồng bộ nằm trên ExternalDataSchema và có thể được thay đổi bất kỳ lúc nào qua external-data-schemas-partial-update. Hầu hết các thay đổi đều không phá hủy (có hiệu lực vào lần đồng bộ tiếp theo), nhưng một số thay đổi (chuyển đổi sync_type, thay đổi khóa chính) yêu cầu xử lý cẩn thận để tránh làm hỏng dữ liệu đã đồng bộ.
playwright-test
posthog
Viết một bài kiểm tra playwright, đảm bảo nó chạy được và không bị lỗi không ổn định.
error-tracking-ruby
posthog
PostHog theo dõi lỗi cho Ruby
authoring-log-alerts
posthog
Tạo cảnh báo log hữu ích, ít nhiễu trên các dịch vụ trong một dự án PostHog. Sử dụng khi người dùng yêu cầu thiết lập cảnh báo cho log của họ, đề xuất các cảnh báo họ nên thêm,…
making-scenes-tab-aware
posthog
Guides converting PostHog frontend scenes to be tab aware for internal scene tabs. Use when adding or refactoring a `SceneExport` scene, fixing state leaking…
posthog-survey-creator
posthog
Tạo và cấu hình khảo sát trong PostHog thông qua hội thoại có hướng dẫn. Sử dụng kỹ năng này khi người dùng muốn tạo khảo sát, thu thập phản hồi người dùng, chạy…
authoring-scouts
posthog
Cách tạo, chỉnh sửa và điều chỉnh các scout PostHog Signals — các tác nhân theo lịch trình quét một dự án và viết báo cáo vào hộp thư đến Signals. Sử dụng khi người dùng…