Slasha 딥다이브
— git push 한 번으로 내 서버가 나만의 PaaS가 된다

1프로젝트 한줄 요약

이 저장소가 대체 무엇인가.

README의 자기소개는 이렇다: "Slasha is a single binary you install on your server. It turns a plain Linux box into your own platform-as-a-service." 실제로 소스를 열어 보면 이 한 줄이 과장이 아니다. Cargo.toml 워크스페이스는 slasha-server(핵심 서버) · slasha-cli(CLI, 서버도 이 바이너리 안에 임베드) · slasha-db(Diesel ORM + SQLite) 세 크레이트로 구성되고, 최종 산출물은 정말로 실행 파일 하나(slasha)다. 이 바이너리 하나가 Git 서버 역할(HTTP Smart Protocol), 도커 빌드·컨테이너 관리자, Caddy 기반 리버스 프록시 컨트롤러, 웹 대시보드(React 빌드 결과를 rust-embed로 바이너리에 통째로 내장) 역할을 동시에 한다.

README가 소개하는 것보다 실제 코드베이스는 훨씬 넓다. 소스를 뜯어보면 Rust 소스만 약 2만 줄(87개 이상의 .rs 파일)에 달하며, README에 언급되지 않은 기능도 다수 구현돼 있다 — GitHub App 연동(웹훅으로 저장소 미러링), 알림/알럿 시스템(임계치 감시 + 알림 발송), Cron 작업 스케줄러, 서버·앱·서비스 메트릭 수집, litestream을 이용한 SQLite 연속 백업(S3 호환 스토리지로) 등이다. 즉 Slasha는 "git push 데모"가 아니라 실제 운영을 염두에 둔 본격 PaaS 서버다.

2왜 주목받는가

"Kubernetes 없는 PaaS" · Rust 단일 바이너리 · railpack 자동 빌드 · 헬스체크 기반 무중단 배포.

최근 몇 년간 "셀프호스팅 PaaS" 카테고리는 이미 Coolify·Dokku·CapRover 같은 검증된 프로젝트들이 자리 잡고 있다. Slasha가 이 붐비는 영역에서 TrendShift 상위권에 오른 이유는 기술적 선택의 결이 다르기 때문이다. 대부분의 경쟁자가 PHP/Node/Go + Bash 스크립트 조합인 반면, Slasha는 Rust 워크스페이스로 서버·CLI를 전부 짜고, 결과물을 의존성 없는 단일 바이너리로 배포한다. 최초 릴리스 v0.1.0이 2026-07-01에 올라온 갓 며칠 된 소프트웨어라는 점, 그리고 README에 동작 원리를 그림(architecture.svg)으로 미리 공개한 점도 눈길을 끈다.

경쟁 셀프호스팅/관리형 PaaS와 무엇이 다른가

3기술 스택 전체 지도

Rust 서버(axum+diesel+bollard) + React Router 대시보드 + Docker/railpack/Caddy 인프라.

Slasha는 "서버(백엔드)"와 "대시보드(프론트엔드)"가 완전히 분리된 코드베이스이면서도, 최종적으로는 rust-embed로 대시보드 빌드 결과를 서버 바이너리 안에 통째로 넣어 파일 하나로 배포한다. 각 레이어를 실제 Cargo.toml/package.json 기준으로 뜯어보자.

백엔드 — Rust 워크스페이스 (crates/)

인증·보안 관련 크레이트도 눈여겨볼 만하다: jsonwebtoken(JWT 발급/검증) · argon2(비밀번호 해시) · zeroize(민감한 값을 메모리에서 확실히 지움) · hmac+sha2(GitHub 웹훅 서명 검증). 그 외 sysinfo(서버 자원 모니터링) · x509-parser(TLS 인증서 파싱) · flate2/async-compression(백업 압축) 등도 포함돼 있다.

프론트엔드 — React Router 대시보드 (web/)

인프라 — 빌드·실행·네트워킹

4아키텍처 심화 분석

git push부터 헬스체크·프록시 동기화까지 — 한 번의 배포가 거치는 전체 파이프라인.

Slasha의 심장은 "git push 하나가 실제 서비스 트래픽 전환까지 자동으로 이어지는 파이프라인"이다. 사용자가 git push slasha main을 치는 순간부터 벌어지는 일을 실제 소스 코드(routing/git.rs·docker/deployment/executor.rs·docker/deployment/build.rs·proxy/sync.rs) 기준으로 재구성하면 이렇다.

① Git 서버 — 진짜 git 프로세스를 감싼 Smart HTTP

많은 사람이 오해하는 부분인데, Slasha는 "git 프로토콜을 처음부터 구현"하지 않는다. routing/git.rs를 보면 axum 라우터가 /git/{slug}/info/refs·git-upload-pack·git-receive-pack 세 엔드포인트를 노출하고, 요청이 오면 서버에 설치된 진짜 git 바이너리를 서브프로세스로 실행해 표준 입출력을 HTTP 스트림과 연결한다. 이것이 GitHub·GitLab이 쓰는 것과 같은 "Smart HTTP" 프로토콜이다. push가 끝나면 post-receive 훅을 임시 디렉터리에 동적으로 만들어, 배포 성공 메시지를 사용자의 git push 콘솔 출력에 그대로 띄운다 — Heroku에 push했을 때 보이는 그 익숙한 초록색 로그가 바로 이 방식이다.

② 빌드 전략 자동 선택 — Dockerfile이 없어도 되는 이유

dockerfile_parser.rs의 detect_build_strategy()는 커밋 루트에 Dockerfile이 있는지만 확인하는 간단한 로직이지만, 그 갈림길이 크다. 있으면 사용자의 Dockerfile로 build_docker()가 그대로 빌드하고, 없으면 railpack이 대신 언어(Node·Python·Rust·Go 등)를 감지해 최적화된 이미지를 자동 생성한다(build_railpack()). 이 두 경로 모두 git archive --format=tar {commit}로 해당 커밋의 스냅샷만 뽑아 빌드 컨텍스트로 쓰기 때문에, 저장소 전체 히스토리가 이미지에 섞여 들어가지 않는다.

③ 컨테이너 명명·라벨링 — 상태를 DB가 아니라 Docker 자체에 새긴다

인상적인 설계 선택 하나는, Slasha가 "지금 뭐가 실행 중인가"를 판단할 때 자체 DB만 믿지 않고 Docker에 직접 물어본다는 점이다. container.rs의 is_web_running()은 slasha.app_id·slasha.process_type=web 라벨과 status=running 필터로 Docker 데몬에게 직접 질의해 답을 얻는다. proxy/sync.rs도 마찬가지로 slasha.managed=true 라벨이 붙은 실행 중 컨테이너를 스캔해 프록시 라우팅 표를 만든다. 이렇게 하면 DB와 실제 컨테이너 상태가 어긋나는(desync) 상황에서도 Docker 자체가 진실의 원천(source of truth)이 되어 자연스럽게 복구된다.

④ 무중단 배포와 롤백 — "선 기동, 후 전환, 실패시 청소"

docker/rollback.rs는 일반적인 try/catch가 아니라 보상 트랜잭션(compensating transaction) 스택을 구현한다 — 배포 단계마다 "실패하면 되돌릴 동작"을 Rollback::register()로 하나씩 쌓아 두고, 정상 완료되면 disarm()으로 무효화하고, 중간에 실패하면 execute()가 쌓인 순서의 역순으로 모두 실행한다. 실제 배포 흐름(run_deployment_inner)에서는 새 컨테이너를 먼저 띄우고 is_web_running으로 살아있음을 확인한 뒤에야 이전 배포를 정지시킨다 — 새것이 확실히 뜬 다음 헌것을 끈다는 순서 자체가 무중단의 핵심이다. 이는 완전한 트래픽 레벨 블루-그린(구버전과 신버전에 동시에 트래픽을 흘리며 서서히 전환하는 방식)이라기보다, "기동 확인 후 전환"에 가까운 실용적 무중단 패턴이라는 점은 짚어 둘 만하다.

⑤ 프록시 동기화 — Caddy를 설정 파일이 아니라 API로 조종

proxy/caddy_client.rs는 Caddy를 설정 파일을 고쳐 재시작하는 전통적 방식이 아니라, Caddy의 Admin API(:2019)에 JSON을 POST해 무중단으로 설정을 갈아 끼운다. sync_routes()가 라벨 기반으로 컨테이너 IP 목록을 모으면, CaddyClient::apply_routes()가 이를 Caddy의 라우트 JSON으로 변환해 밀어 넣는다. 운영 환경에서는 여기에 automatic_https가 켜져 Let's Encrypt로 인증서를 자동 발급/갱신하고, 개발 환경(SLASHA_ENV=development)에서는 자체 서명 내부 인증서로 대체되며 리다이렉트가 꺼진다 — 코드에 이 분기가 명시적으로 존재한다.

⑥ 보안 터널 — 포트를 열지 않고 관리형 DB에 접속하기

tunnel/mod.rs의 구현 방식은 예상외로 단순하면서 영리하다. 포트 포워딩이나 SSH 터널을 새로 짜는 대신, Docker의 exec 기능을 그대로 활용한다 — CLI가 서버와 WebSocket을 열면, 서버는 해당 서비스 컨테이너 안에서 psql/mysql/redis-cli류 클라이언트(또는 Redis는 nc)를 docker exec로 실행하고, 그 표준 입출력을 WebSocket으로 그대로 중계한다. 즉 데이터베이스 포트를 인터넷에 노출하지 않고도, "컨테이너 안에서 로컬로 접속하는 것"을 원격에서 그대로 재현하는 방식이다.

5디렉토리 구조 해부

최상위 레이아웃 + crates/slasha-server의 실제 모듈 구성.

6학습 포인트 (기술별)

이 저장소에서 실제로 무엇을 배울 수 있는가 + 각 주제 실습 아이디어.

7하드웨어 / 시스템 요구사항

서버(운영)와 로컬(개발) 요구사항을 나눠서.

8직접 해볼 수 있는 실습 과제

난이도별 5단계 — 설치해 굴려 보고, 코드를 고쳐 보고, 직접 만들어보기.

과제 1 · 로컬에 Slasha 통째로 띄워보기 난이도 ★☆☆☆☆

가장 먼저 할 일은 실제로 굴려 보는 것이다. 저장소를 클론해 make dev 한 줄이면 .env.example이 .env로 복사되고, 서버(cargo run)와 웹 대시보드(bun run dev)가 동시에 뜬다. SLASHA_PLATFORM_DOMAIN=slasha.localhost로 브라우저에서 대시보드에 접속해 계정을 만들고 화면 구조를 익히는 것이 목표다.

# 저장소 클론 후
git clone https://github.com/slashacom/slasha.git
cd slasha
make dev              # .env 자동 생성 + 서버·대시보드 동시 실행
# 브라우저에서 http://slasha.localhost:3000 접속

과제 2 · 첫 앱을 git push로 배포해 보기 난이도 ★★☆☆☆

대시보드나 CLI로 앱을 하나 만들고(slasha create my-app), Node/Python 같은 아주 간단한 "Hello World" 웹 서버 프로젝트를 git push slasha main으로 배포해 본다. Dockerfile을 일부러 넣지 않고 push해서 railpack이 언어를 자동 감지해 빌드하는 과정을 로그로 관찰하고, 그다음엔 직접 Dockerfile을 추가해 빌드 전략이 어떻게 바뀌는지 비교한다.

// 핵심 골격 (README CLI 사용법 요약)
slasha create my-app
slasha link --app my-app        // cwd에 .slasha 파일 기록
git remote add slasha <서버가 알려준 git URL>
git push slasha main            // 여기서 build_railpack() 또는 build_docker() 실행
slasha deployments logs --follow

과제 3 · 관리형 PostgreSQL을 붙이고 터널로 접속하기 난이도 ★★★☆☆

slasha provision --kind postgres --name db --version 16로 관리형 DB를 띄운 뒤, 앱 코드에서 ${{db.DATABASE_URL}} 같은 서비스 참조 환경변수로 연결한다. 그다음 로컬 컴퓨터에서 slasha services proxy db --port 5432로 터널을 열어 psql로 직접 접속해 본다 — 포트를 서버에 열지 않고도 DB에 접속되는 걸 확인하는 것이 핵심이다.

과제 4 · 커스텀 도메인 + 자동 HTTPS 확인하기 난이도 ★★★☆☆

실제 소유한 도메인(서브도메인도 가능)의 DNS를 서버 IP로 돌린 뒤 slasha domains add app.example.com을 실행하고, Caddy가 Let's Encrypt 인증서를 자동 발급하는 과정을 proxy/caddy_client.rs 코드와 나란히 관찰한다. 브라우저 개발자 도구에서 인증서 발급자·유효기간을 확인해 본다.

과제 5 · 새로운 CLI 서브커맨드를 직접 추가해 보기 난이도 ★★★★☆

clap_app.rs의 Command enum에 새 항목(예: 배포 히스토리를 CSV로 내보내는 export 명령)을 추가하고, 대응하는 서버 API 엔드포인트를 routing/api/에 만들어 연결한다. 기존 deployments.rs의 dispatch() 패턴을 그대로 따라 하면 큰 어려움 없이 구조를 익힐 수 있다. Rust 워크스페이스에서 CLI ↔ 서버 ↔ DB 세 크레이트가 어떻게 서로 참조하는지 실전으로 배우는 과제다.

9관련 기술 심화 학습 로드맵

이 레포 하나로 웹서버·컨테이너·네트워킹·배포 이론을 8주에 걸쳐 정리하는 코스.

10핵심 키워드 사전

이 문서에 등장한 전문 용어를 한 곳에 모음.

11참고 링크

더 깊이 파고들고 싶다면.