Ghostty Meninggalkan GitHub: Dampaknya Bagi Pembuat Alat Pengembang

Pada 28 April 2026, Mitchell Hashimoto mengumumkan bahwa Ghostty, emulator terminal sumber terbukanya, akan meninggalkan GitHub. Hashimoto adalah pengguna GitHub 1299, bergabung pada Februari 2008, dan memakai platform ini hampir setiap hari selama lebih dari 18 tahun. Namun, riwayat itu tidak cukup ketika ia mulai mencatat pemadaman “hampir setiap hari ada X”. Pada hari pengumuman, kegagalan GitHub Actions menghalangi proses review PR selama dua jam. Kesimpulannya jelas: “Ini bukan lagi tempat untuk pekerjaan serius jika hanya menghalangi Anda selama berjam-jam per hari, setiap hari.”

Coba Apidog hari ini

Jika Anda membangun alat pengembang, pengumuman ini layak dibaca sebagai studi kasus keandalan. Hashimoto bukan pengguna GitHub biasa: ia turut mendirikan HashiCorp di atas GitHub dan merilis Terraform, Vagrant, Vault, Consul, serta Boundary melalui platform tersebut. Ketika pengguna seperti ini pergi karena alasan keandalan, masalahnya bukan sekadar “satu proyek pindah forge”, tetapi sinyal tentang risiko platform dependency, lock-in, dan biaya downtime pada alat yang dipakai developer setiap hari.

Untuk konteks tambahan tentang perubahan workflow developer era AI di GitHub, baca cara menulis file AGENTS.md dan penggunaan GitHub Copilot serta API penagihan untuk tim. Untuk contoh otomatisasi di sekitar celah keandalan GitHub, lihat tulisan tentang bot triage Clawsweeper.

TL;DR

• Mitchell Hashimoto mengumumkan pada 28 April 2026 bahwa Ghostty akan meninggalkan GitHub menuju forge yang belum disebutkan namanya.
• Alasannya bukan fitur atau harga, tetapi keandalan: pemadaman GitHub Actions dan degradasi platform yang ia dokumentasikan sebagai “hampir setiap hari ada X”.
• Repo Ghostty di GitHub akan tetap tersedia sebagai mirror hanya-baca; pengembangan aktif, issue, PR, dan CI akan dipindahkan secara bertahap.
• Untuk pembuat alat developer, pelajarannya sederhana: setelah produk Anda masuk jalur kritis workflow pengguna, reliability mengalahkan fitur.
• Untuk tim API, mitigasinya adalah dekopling: mock dependency, dukung lebih dari satu provider, dan latih jalur migrasi sebelum dibutuhkan. Apidog mendukung pola ini melalui mock server, environment, dan contract testing.

Apa yang dikatakan Hashimoto

Dalam postingan pengumuman, Hashimoto tidak menulis manifesto panjang. Ia menjelaskan urutannya secara langsung:

1. Ia mulai mencatat pemadaman dan degradasi GitHub.
2. Catatan itu terisi lebih cepat dari yang ia perkirakan.
3. Pada hari ia menulis pengumuman, GitHub Actions bermasalah dan memblokir review PR selama dua jam.
4. Ia menyimpulkan GitHub tidak lagi cukup andal untuk workflow Ghostty.

Pada 27 April 2026, sehari sebelum pengumuman, terjadi pemadaman besar GitHub yang memengaruhi Actions, Packages, dan API. Namun keputusan Hashimoto bukan reaksi spontan terhadap satu insiden. Ia sudah melacak pola tersebut selama berbulan-bulan.

Batas migrasinya juga jelas:

• Ghostty akan pindah.
• Proyek Hashimoto lain tetap di GitHub untuk saat ini.
• Repositori Ghostty tetap ada sebagai mirror hanya-baca.
• Forge baru akan menangani pengembangan aktif, issue, pull request, dan CI.
• Migrasi dilakukan bertahap, bukan cutover satu hari.

Yang tidak ia bahas sama pentingnya: tidak ada komplain utama tentang fitur, harga, atau arah produk. Masalahnya adalah permukaan kerja yang ia butuhkan berhenti berfungsi selama jam produktif.

Kenapa ini penting untuk pembuat alat developer

Sebagian diskusi berfokus pada pertanyaan “Ghostty akan pindah ke mana?”. Untuk developer tooling, pertanyaan yang lebih penting adalah:

Apakah tool Anda tetap bisa dipakai ketika pengguna sedang benar-benar membutuhkannya?

Ada tiga alasan pengumuman ini relevan.

1. Penggunanya kredibel

Hashimoto telah membangun alat infrastruktur yang dipakai perusahaan besar. Ketika ia mengatakan GitHub tidak cukup andal untuk pekerjaan serius, audiens yang mendengar bukan hanya pengguna terminal, tetapi juga tim platform, CTO, dan engineering manager yang mengandalkan GitHub sebagai substrat kerja.

2. Alasannya universal

Ia tidak pergi karena isu politik, Copilot, Microsoft, AI training, atau harga. Ia pergi karena downtime.

Itu membuat pesan ini sulit diabaikan. Semua tim engineering memahami satu pertanyaan dasar:

Apakah alat ini tersedia ketika workflow saya bergantung padanya?

3. Nadanya seperti postmortem

Tidak ada kemarahan besar. Postingan itu terbaca seperti laporan insiden dari seseorang yang sudah mencoba bertahan. Justru itu yang membuatnya kuat: pengguna lama berhenti percaya setelah akumulasi kegagalan kecil terlalu sering terjadi.

Jalankan audit reliability pada produk Anda

Jika produk Anda berada di jalur kritis developer, gunakan kasus ini sebagai checklist.

1. Berapa banyak pengguna yang bisa menulis jurnal serupa?

Ambil data 90 hari terakhir:

• insiden di status page,
• degradasi internal yang tidak pernah dipublikasikan,
• backlog queue,
• error rate,
• timeout,
• kegagalan integrasi pihak ketiga.

Lalu petakan ke jam kerja pelanggan utama. Jangan hanya tanya “berapa uptime total?”, tetapi:

Berapa jam produktif pengguna berat yang hilang karena menunggu produk kita?

Jika jawabannya “lebih dari nol per minggu untuk pengguna berat”, Anda perlu memperbaiki jalur kritis.

2. Apakah reliability Anda membaik atau menurun?

Hashimoto tidak bereaksi terhadap satu insiden, tetapi terhadap tren.

Gunakan error budget per komponen:

Component          SLO       Error budget used    Trend
API gateway        99.95%    42%                  stable
CI integration     99.9%     88%                  worsening
Webhook delivery   99.9%     63%                  improving
Mock service       99.95%    21%                  stable

Jika satu komponen masih memenuhi SLA tetapi tren insidennya memburuk, jangan tunggu sampai pelanggan menulis blog post.

3. Apakah status page Anda cukup jujur?

Pengguna membuat “jurnal pribadi” ketika sinyal publik tidak dipercaya.

Status page yang berguna harus menunjukkan:

• partial outage,
• regional degradation,
• latency tinggi,
• queue tertunda,
• webhook delay,
• impact pada API tertentu,
• estimasi workaround jika ada.

Contoh status yang lebih berguna:

Degraded performance: GitHub webhook ingestion

Impact:
- Webhook delivery delay up to 35 minutes
- Pull request automation may run late
- Manual re-run is available

Workaround:
- Use CLI sync command
- Disable blocking checks temporarily if policy allows

Bukan hanya:

We are investigating reports of degraded performance.

4. Ukur availability berdasarkan workflow pengguna

Uptime 99,95% tidak banyak artinya jika downtime selalu terjadi pada jam kerja puncak.

Untuk developer tooling, ukur availability terhadap workflow nyata:

• review PR,
• release pipeline,
• dependency update,
• test run,
• API contract validation,
• deploy approval.

Jika satu sesi review PR berdurasi empat jam dan platform mati dua jam di tengahnya, dampaknya bukan “hanya dua jam downtime”. Dampaknya adalah satu sesi kerja gagal.

Lock-in “selalu GitHub”

Kalimat Hashimoto yang paling penting:

“Tidak pernah menjadi pertanyaan bagi saya di mana saya akan menempatkan proyek-proyek saya: selalu GitHub.”

Itulah lock-in berbasis kebiasaan.

Secara teknis, repo Git mudah dipindahkan:

git remote add mirror [e-mail]:org/repo.git
git push --mirror mirror

Namun yang sulit dipindahkan adalah ekosistem di sekitar repo:

• issue tracker,
• pull request history,
• review comments,
• GitHub Discussions,
• GitHub Actions secrets,
• workflow CI,
• CODEOWNERS,
• release artifacts,
• package registry,
• OAuth identity,
• marketplace integration.

Untuk pembuat alat developer, risikonya lebih besar. Jika produk Anda:

• berjalan sebagai GitHub Action,
• didistribusikan melalui GitHub Marketplace,
• memakai GitHub OAuth,
• membaca GitHub API,
• menerbitkan release ke GitHub Packages,

maka reliability produk Anda adalah turunan dari reliability GitHub.

Pengguna tidak selalu memisahkan penyebab. Jika automation Anda gagal karena GitHub API down, pengalaman pengguna tetap: “tool ini gagal”.

Cara mendekopling dependency GitHub

Dekopling tidak harus berarti langsung meninggalkan GitHub. Mulai dari pola yang bisa diuji.

1. Buat adapter, bukan import langsung

Buruk:

import { Octokit } from "@octokit/rest";

export async function createIssue(title: string, body: string) {
  const client = new Octokit({ auth: process.env.GITHUB_TOKEN });

  return client.rest.issues.create({
    owner: "org",
    repo: "repo",
    title,
    body,
  });
}

Lebih baik:

export interface IssueProvider {
  createIssue(input: {
    repo: string;
    title: string;
    body: string;
  }): Promise<{ id: string; url: string }>;
}

Implementasi GitHub:

import { Octokit } from "@octokit/rest";
import type { IssueProvider } from "./IssueProvider";

export class GitHubIssueProvider implements IssueProvider {
  constructor(private client: Octokit, private owner: string) {}

  async createIssue(input: {
    repo: string;
    title: string;
    body: string;
  }) {
    const res = await this.client.rest.issues.create({
      owner: this.owner,
      repo: input.repo,
      title: input.title,
      body: input.body,
    });

    return {
      id: String(res.data.id),
      url: res.data.html_url,
    };
  }
}

Nanti Anda bisa menambahkan provider GitLab, Forgejo, atau fallback internal tanpa mengubah business logic.

2. Mirror repo secara berkala

Contoh GitHub Actions untuk mirror ke remote kedua:

name: Mirror repository

on:
  schedule:
    - cron: "0 */6 * * *"
  workflow_dispatch:

jobs:
  mirror:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout full history
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Push mirror
        run: |
          git remote add mirror "$MIRROR_URL"
          git push --mirror mirror
        env:
          MIRROR_URL: ${{ secrets.MIRROR_URL }}

Catatan: jika GitHub Actions sedang down, job ini juga ikut gagal. Untuk jalur kritis, jalankan mirror dari runner eksternal atau scheduler terpisah.

3. Dokumentasikan fallback manual release

Jika CI utama gagal, tim harus tahu cara rilis manual.

Contoh minimal:

# 1. Build
npm ci
npm run test
npm run build

# 2. Tag release
git tag v1.2.3
git push origin v1.2.3

# 3. Publish package
npm publish

# 4. Upload artifact ke storage cadangan
aws s3 cp ./dist/app.tar.gz s3://releases/app/v1.2.3/app.tar.gz

Dokumen fallback harus menjawab:

• siapa yang boleh menjalankan,
• kredensial ada di mana,
• langkah verifikasi apa yang wajib,
• bagaimana rollback dilakukan,
• kanal komunikasi apa yang dipakai.

Alternatif forge secara singkat

Hashimoto belum menyebut tujuan akhir Ghostty. Pada akhir April 2026, opsi kredibel mencakup:

• Forgejo — hard fork Gitea, FOSS, dikelola oleh Codeberg e.V. Cocok untuk proyek yang memprioritaskan ekosistem terbuka.
• Codeberg — instance Forgejo yang di-host sebagai nirlaba. Gratis untuk open source, tetapi belum memiliki skala Actions seperti GitHub.
• GitLab — CI/CD kuat, fitur lengkap, dukungan komersial. Sebagian komunitas FOSS memperdebatkan arah lisensinya.
• Sourcehut — workflow berbasis email, minimalis, cepat. Sangat disukai oleh niche tertentu.
• Forgejo/Gitea self-hosted — kontrol maksimum, tetapi tanggung jawab operasional juga maksimum.
• Radicle — peer-to-peer tanpa host pusat. Menarik untuk federasi, tetapi mungkin terlalu awal untuk proyek publik besar.

Tidak ada opsi yang mengganti seluruh permukaan GitHub secara sempurna. Itulah inti masalahnya: ketika satu platform menyerap repo, issue, CI, release, package, dan identity, migrasi menjadi proyek besar.

Pelajaran untuk tim API

Jika Anda membangun API atau alat API, pola risikonya sama.

Ganti:

GitHub Actions

dengan:

API upstream yang diandalkan produk Anda

Ganti:

issue dan PR

dengan:

kanal tempat pelanggan melaporkan masalah

Pertanyaannya tetap:

Berapa banyak pekerjaan pelanggan yang bergantung pada layanan yang tidak Anda kontrol?

1. Mock semua dependency eksternal

Developer harus tetap bisa bekerja ketika API upstream mati.

Minimal, Anda butuh:

• mock server untuk local development,
• fixture response realistis,
• contract test,
• mode offline untuk CI,
• data contoh untuk edge case.

Contoh respons mock:

{
  "id": "chatcmpl_mock_123",
  "object": "chat.completion",
  "created": 1710000000,
  "model": "provider-a-chat",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Mock response untuk development."
      },
      "finish_reason": "stop"
    }
  ]
}

Dengan Apidog, definisi request/response yang sama dapat digunakan untuk dokumentasi, pengujian, dan mock server. Untuk contoh ekosistem API bergaya OpenAI, lihat cara menggunakan GPT-5.5 API.

2. Uji beberapa provider

Jika produk Anda membungkus satu provider AI atau API eksternal, perbedaan antara outage total dan failover sering kali hanya desain integrasi.

Contoh struktur environment:

API_PROVIDER=openai
API_BASE_URL=https://api.openai.example/v1
API_KEY=***

API_PROVIDER_FALLBACK=provider_b
API_FALLBACK_BASE_URL=https://api.provider-b.example/v1
API_FALLBACK_KEY=***

Jangan hanya menjalankan test terhadap provider utama. Jalankan test kontrak terhadap semua provider yang Anda klaim dukung.

Contoh pseudocode:

const providers = ["openai", "anthropic", "mistral"];

for (const provider of providers) {
  test(`chat completion contract: ${provider}`, async () => {
    const client = createClient(provider);

    const res = await client.chat({
      messages: [{ role: "user", content: "ping" }],
    });

    expect(res).toHaveProperty("id");
    expect(res.choices[0].message.content).toBeDefined();
  });
}

3. Pisahkan pipeline rilis dari platform hosting

Jika CI sepenuhnya bergantung pada GitHub Actions, maka saat Actions down, rilis Anda berhenti.

Mitigasi praktis:

• mirror pipeline kritis ke runner lain,
• simpan build script di repo, bukan hanya YAML CI,
• dukung release manual,
• simpan artifact di storage cadangan,
• pisahkan signing key dari satu platform CI.

Workflow gaya Apidog untuk API yang lebih tangguh

Pola implementasi yang bisa diterapkan tim API:

1. Unduh Apidog dan buat satu project untuk setiap API upstream penting.
2. Definisikan schema request dan response sekali.
3. Generate mock server dari schema tersebut agar local development tidak tergantung layanan upstream.
4. Simpan credential sebagai environment secret.
5. Jalankan request yang sama terhadap:
   • dev untuk mock,
   • staging untuk sandbox,
   • prod untuk live API.
6. Tambahkan contract test pada setiap release.
7. Jalankan contract test terhadap setiap provider yang Anda dukung.
8. Saat upstream terdegradasi, arahkan environment ke mock atau provider cadangan agar development dan testing tetap berjalan.

Pola ini tidak spesifik Ghostty atau AI. Ini pola umum untuk mengurangi risiko dependency eksternal.

Checklist praktis untuk stack Anda

Gunakan checklist ini untuk audit internal.

Repository dan forge

• [ ] Mirror repo aktif ke forge kedua.
• [ ] Pastikan mirror mencakup tag dan branch.
• [ ] Dokumentasikan cara menjadikan mirror sebagai primary.
• [ ] Simpan backup issue/PR jika proyek sangat bergantung pada riwayat tersebut.

CI/CD

• [ ] Identifikasi job CI yang benar-benar kritis.
• [ ] Sediakan runner kedua atau jalur manual.
• [ ] Simpan build command di script repo.
• [ ] Dokumentasikan release manual.
• [ ] Uji fallback minimal sekali per kuartal.

API dependency

• [ ] Daftar semua API eksternal di jalur kritis.
• [ ] Buat mock untuk setiap API penting.
• [ ] Jalankan contract test otomatis.
• [ ] Tambahkan timeout dan retry dengan backoff.
• [ ] Pastikan failure mode jelas: fail open, fail closed, atau degrade gracefully.

Contoh retry sederhana:

async function withRetry<T>(
  fn: () => Promise<T>,
  retries = 3
): Promise<T> {
  let lastError: unknown;

  for (let attempt = 1; attempt <= retries; attempt++) {
    try {
      return await fn();
    } catch (err) {
      lastError = err;
      const delay = Math.min(1000 * 2 ** attempt, 8000);
      await new Promise((resolve) => setTimeout(resolve, delay));
    }
  }

  throw lastError;
}

Observability

• [ ] Status page menampilkan partial outage.
• [ ] Latency dan queue delay terlihat.
• [ ] Error budget dibaca rutin.
• [ ] Insiden kecil tetap dicatat.
• [ ] Tren reliability dipantau, bukan hanya SLA bulanan.

Untuk contoh yang lebih spesifik pada tooling API, baca membangun workflow tangguh yang bertahan dari pemadaman provider, yang memakai DeepSeek dan OpenAI sebagai contoh multi-provider.

FAQ

Ke mana Ghostty akan pindah?

Hashimoto belum menyebut tujuan akhir dalam postingan pengumuman. Ia mengatakan sedang berdiskusi dengan beberapa penyedia, baik komersial maupun FOSS. Migrasi akan dilakukan bertahap, dan repo GitHub Ghostty saat ini tetap menjadi mirror hanya-baca.

Apakah GitHub benar-benar tidak andal?

Secara angka uptime umum, GitHub masih kompetitif dengan platform besar lain. Namun keluhan Hashimoto adalah pola degradasi parsial dan pemadaman yang mengganggu jam kerja nyata. Untuk pengguna yang workflow-nya berada di jalur kritis GitHub Actions, Packages, atau API, beberapa jam gangguan per minggu bisa cukup untuk mengubah keputusan platform.

Haruskah saya memindahkan repo dari GitHub sekarang?

Untuk sebagian besar tim, langsung pindah penuh mungkin belum sepadan. Namun mirroring hampir selalu layak. Biayanya rendah, dan Anda mendapat jalur cadangan saat GitHub atau GitHub Actions bermasalah.

Apakah ini memengaruhi GitHub Copilot atau GitHub Actions?

Postingan Hashimoto tidak secara khusus membahas Copilot. Pemicu langsung pada hari pengumuman adalah pemadaman Actions yang menghalangi review PR. Jika tim Anda memakai Copilot, informasi terkait penagihan dapat dilihat di penggunaan GitHub Copilot dan API penagihan untuk tim.

Apa artinya untuk alat developer era AI yang bergantung pada GitHub API?

Bot review, triage issue, server MCP, dan automation lain yang membungkus GitHub API ikut mewarisi profil reliability GitHub. Mitigasinya sama seperti dependency pihak ketiga lain: cache data penting, desain fallback, mock API upstream, dan jalankan contract test. Contoh terkait dapat dilihat di tulisan tentang bot triage Clawsweeper.

Apakah ini awal tren meninggalkan GitHub?

Mungkin, tetapi tidak akan cepat. Memigrasikan proyek non-trivial dari GitHub membutuhkan waktu karena issue, PR, CI, release, dan integrasi identity ikut terikat. Sinyal penting dari kasus Hashimoto adalah bahwa bagi sebagian pengguna berat, biaya migrasi mulai terlihat lebih kecil daripada biaya reliability yang memburuk.

Siapa yang termasuk “pembuat alat developer”?

Siapa pun yang membuat software yang dipakai developer lain dalam workflow harian: terminal, editor, CI runner, API client, package registry, monitoring tool, bot review, atau asisten coding AI. Jika tool Anda berada di antara developer dan proses shipping, maka reliability produk Anda adalah bagian dari reliability workflow mereka.