# Garnix가 종료됩니다

> Clean Markdown view of GeekNews topic #29974. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=29974](https://news.hada.io/topic?id=29974)
- GeekNews Markdown: [https://news.hada.io/topic/29974.md](https://news.hada.io/topic/29974.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-05-29T09:09:23+09:00
- Updated: 2026-05-29T09:09:23+09:00
- Original source: [discourse.nixos.org](https://discourse.nixos.org/t/garnix-is-shutting-down-not-oc/77895)
- Points: 1
- Comments: 1

## Topic Body

- **garnix**는 Shopify와 합류하는 전환 과정에서 호스팅 서비스를 2026년 7월 15일 종료할 예정임
- garnix **코드베이스**는 오픈소스로 공개되어, 사용자가 자체 인스턴스나 공유 인스턴스로 이전할 수 있게 됨
- 공개 **커뮤니티 인스턴스** 운영에 관심 있는 사용자는 garnix 팀에 연락할 수 있으며, 팀도 관련 대화를 원함
- 2026년 7월 15일 모든 **사용자 데이터**가 삭제되며, 빌드 산출물도 삭제 대상에 포함됨
- 보관할 데이터와 **빌드 산출물**은 종료일 전에 직접 다운로드해야 하며, 현재 공지는 이메일 인용 형태로 공유됨

---

### 서비스 종료와 코드 공개
- **garnix**는 Shopify와 합류하며, 이 전환의 일부로 호스팅된 garnix 서비스를 2026년 7월 15일 종료함
- garnix 코드베이스는 오픈소스로 공개되어 사용자가 자체 인스턴스나 공유 인스턴스로 옮겨갈 수 있게 됨
- 공개 커뮤니티 인스턴스 운영에 관심 있는 사용자는 garnix 팀에 연락할 수 있음

### 사용자 데이터와 이전 준비
- 2026년 7월 15일 **모든 사용자 데이터**가 삭제되며, 빌드 산출물도 포함됨
- 보관할 데이터나 빌드 산출물은 종료일 전에 직접 다운로드해야 함
- 종료 공지는 [garnix.io](http://garnix.io)에서 확인되지 않았고, [contact@garnix.io](mailto:contact@garnix.io)에서 받은 이메일 내용을 인용한 형태로 공유됨
- garnix 팀은 Open Collective 시절의 기부와 피드백을 포함한 커뮤니티 지원에 감사를 전했으며, 팀 구성원은 Alex David, Sönke Hahn, Julian K. Arni로 명시됨

## Comments



### Comment 58495

- Author: neo
- Created: 2026-05-29T09:09:24+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/4msjpt/garnix_is_shutting_down) 
- 안타깝네요! 롤링 배포 문제를 풀기 위해 **서비스 의존 URL**을 서비스 빌드에 박아 넣는 글을 정말 좋아했음  
  https://garnix.io/blog/call-by-hash/

- Garnix가 뭔지 궁금한 사람을 위해:  
  Garnix는 **Nix화된 flake 기반 GitHub 저장소**용 CI 서비스임  
  출처: https://github.com/garnix-io/garnix-ci#garnix

- Garnix는 지금까지 써본 CI 시스템 중 압도적으로 최고였음  
  GitHub Actions가 아직 실행기를 찾고 있을 때 Garnix는 이미 빌드를 끝냈고, 내 중간 정도 복잡도의 **Rust 프로젝트**도 보통 1분 안에 끝났음  
  문서만 바꿨을 때는 더 빨랐고, 문서도 실제로 빌드했음  
  물론 Nix 덕분이지만 Garnix가 그 통합을 정말 잘했음  
  빌드 시스템과 통합된 CI는 매번 S3에서 파일시스템 절반짜리 tar를 내려받아 캐시를 덧붙이는 방식보다 훨씬 잘 동작할 수 있음  
  게다가 Nix 기반이라 로컬에서 빌드하는 것과 정확히 같은 것을 빌드하므로, “yaml 오타 고치기, push, 10분 기다리기, 다음 오류 보기, 디버그 출력 추가, 다시 push...” 같은 긴 피드백 루프가 없음  
  로컬에서 빌드되면 CI에서도 동작함

- 아쉽네요. 지난 일주일쯤 이상한 문제가 몇 개 보였지만 크게 신경 쓰지는 않았음  
  GitHub만 지원하는 점은 좀 불만이었지만 그래도 훌륭한 서비스였음  
  주말에 **오픈소스 버전**을 살펴보고 자체 호스팅이 현실적인지 판단해볼 생각이고, Nix 빌드 대안이 있으면 알려주면 좋겠음

- 출시 때부터 garnix를 써왔는데 종료한다니 꽤 아쉽네요  
  **Nix CI**나 자체 호스팅 가능한 해법을 아는 사람이 있으면 알려주면 좋겠음  
  주로 garnix를 캐시로 썼고, 공개된 체크 상태를 기반으로 자동 병합 워크플로도 구성해둔 상태였음
  - tangled.org에서 곧 비슷한 것을 공개할 예정임. **자체 호스팅**도 가능할 것임
  - garnix가 오픈소스로 공개되는 듯하니 자체 호스팅 후보가 될 수도 있음  
    고객은 아니었고 집에서만 Nix를 쓰지만, 자체 호스팅 방법은 꼭 살펴볼 생각임

- 다음 내용만 아니었다면 완전히 주제 밖이었겠지만:  
  “하지만 garnix 코드베이스를 오픈소스로 공개하며, [여기](https://github.com/garnix-io/garnix-ci)에서 볼 수 있습니다”  
  이 부분은 주제에 맞고 흥미롭다고 봄  
  회사에서 **Nix에 전면 투자**하고 있는데, 감정이 꽤 복잡함  
  부정적인 느낌의 대부분은 Nix가 정말 훌륭한 기술이면서도, 아직 매우 젊은 외계 유물처럼 느껴진다는 데서 옴  
  Nix는 흥미롭고 가치 있는 일이 엄청나게 많이 남아 있어서 기대됨  
  Nix를 도입한다는 건 기존 플랫폼들이 오랫동안 쌓아온 편의 기능을 상당수 포기한다는 뜻이라, Garnix를 비롯해 Nix 생태계의 여러 도구를 살펴보고 있었음  
  실제로 회사에서는 원래라면 공짜로 얻을 “기본” 기능에 훨씬 많은 노력을 쓰고 있음  
  예를 들어 GitHub Actions에서 검증을 돌리는 것도 일반 프로젝트보다 더 복잡하고, 캐싱·병렬화 같은 요소가 견고하고 빠른 빌드에 매우 중요함  
  Nix 생태계를 발전시키는 회사들이 크게 성장하거나, 누군가 **Nix 거인들의 어깨** 위에 세상을 뒤흔들 무언가를 만들 것 같음  
  안타깝게도 Garnix는 더 큰 조직에 흡수된 선구자 중 하나처럼 보임
  - 재미있는 사실은 Nix가 그렇게 젊지 않다는 것임  
    Docker보다 몇 년 앞서 나왔고, 단지 늦게 피어난 기술이라 최근에야 인기를 얻었음

- garnix가 오픈소스가 된 지금 **GitHub와 분리**하기가 얼마나 어려울지 궁금함  
  flake와 분리하는 건 꽤 쉬워야 함. flake는 진짜가 아니고 당신을 해칠 수 없음
  - garnix를 볼 때마다 [창밖으로 스폰지밥과 패트릭이 즐거워하는 걸 질투하며 보는 징징이](https://knowyourmeme.com/memes/squidward-looking-out-the-window) 같은 기분이었음  
    이 가능성은 확실히 기대됨

- 살짝 주제를 가로채면, CI를 Nix로 바꾸려 하는데 개발/CI 환경이 큼  
  주된 이유는 전체 브라우저가 여러 개 들어가기 때문이고, **nix build**나 캐시 복원을 피할 방법을 못 찾겠음  
  1Gbit 환경에서 10GB를 복원하는 것조차 너무 느림  
  Docker는 자체 호스팅 실행기를 쓰면 이 문제가 해결되어 있음  
  Docker 이미지를 만들어 CI 실행기가 뜨는 호스트에 캐시로 유지하면 됨  
  그런데 Nix에서는 이걸 어떻게 하는지 모르겠음  
  개발 환경에 필요한 모든 것이 이미 들어 있는 **nix store**를 공유할 방법이 필요하고, 그 저장소에 체크인된 실제 개발 환경 flake에서 파생되어야 함  
  이런 건 존재하지 않는 것 같지 않나?
  - 잘 이해가 안 됨. 실행기를 직접 호스팅하고 해당 워크플로에 필요한 것으로 `/nix/store`를 미리 채워두면, OCI 이미지와 마찬가지로 그냥 거기에 있는 것 아닌가?  
    예전 직장에서는 자체 GitLab 실행기를 운영했고, 서비스에 투입하기 전에 최근 빌드 산출물 세트를 인스턴스화해서 미리 데워두었음  
    그러면 작업들은 `/nix/store`에 캐시된 것을 그대로 사용했음