GitHub
제작자: github
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
컴퓨터 또는 클라우드★ 34,245MIT4일 전 업데이트
설치
Heliograph
개요
제작자가 쓴 설명(영어 원문)
Run commands on a machine you cannot SSH into. Air-gapped, bastion-only, change-controlled.
PopNx MCP의 세 기둥
이 세 가지는 절대 하나의 점수로 합치지 않아요. 의견, 측정, 인기는 서로 다른 것이니까요.
- 사용자 의견i아직 리뷰가 없어요리뷰는 다음 단계에서 계정 기능과 함께 열려요
- 우리의 기본 점검i1개 중 1개 통과공개된 정보로 점검했으며, 코드는 아직 스캔하지 않았어요
- 사용 정도i아직 측정 안 함★ –
할 수 있는 일
이 서버는 아직 쉬운 말로 된 요약을 쓰지 못했어요. 아래는 레지스트리에서 읽어 온 사실이에요.
- 연결 방식: 내 컴퓨터에서 실행
- 전송 방식: stdio
- 카테고리: 개발자 도구
설치
쓰고 있는 AI 앱을 고른 다음 설정을 복사하세요.
설치하기 전에
- 기본 점검: 1개 중 1개 통과
- 내 컴퓨터에서 내 사용자 계정의 권한(파일, 네트워크, 앱)으로 실행돼요.
- 레지스트리에 입력해야 할 키가 나와 있지 않아요.
필요한 것
- npmNode.js 설치(npx 명령어용)
어떤 앱을 쓰세요?
위에서 앱을 고르세요. 기억해 두었다가 다음부터는 버튼에 “…에 설치”라고 표시해요.
Claude Desktop → Settings → Developer → Edit Config를 열고 claude_desktop_config.json에 이 내용을 붙여 넣으세요
{
"mcpServers": {
"heliograph": {
"command": "npx",
"args": [
"-y",
"@dbhq/heliograph",
"mcp"
]
}
}
}터미널에서 이 명령어를 실행하세요
claude mcp add heliograph -- npx -y @dbhq/heliograph mcp또는 설정을 직접 복사하기
프로젝트의 .cursor/mcp.json 또는 ~/.cursor/mcp.json에 붙여 넣으세요
{
"mcpServers": {
"heliograph": {
"command": "npx",
"args": [
"-y",
"@dbhq/heliograph",
"mcp"
]
}
}
}브라우저가 앱을 열지 물어본 다음, 앱이 설정을 보여 주고 확인을 요청해요. 키 값은 비워 두니 직접 입력하세요.
또는 설정을 직접 복사하기
프로젝트의 .vscode/mcp.json에 붙여 넣으세요
{
"servers": {
"heliograph": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@dbhq/heliograph",
"mcp"
]
}
}
}브라우저가 앱을 열지 물어본 다음, 앱이 설정을 보여 주고 확인을 요청해요. 키 값은 비워 두니 직접 입력하세요.
이 서버는 내 컴퓨터에서 실행되는데, ChatGPT는 인터넷에 있는 서버에만 연결할 수 있어요. 다른 앱을 고르세요.
선택한 앱은 이 기기의 쿠키에만 저장돼요. 계정은 필요 없어요.
이 설정은 제작자의 레지스트리 정보로 만들었어요. README와 다르면 README를 따르세요.
할 수 있는 일
내 컴퓨터에서 실행돼요. 설치하면 AI 앱에 도구 목록이 나타나요.
기본 점검i
누구나 볼 수 있는 정보를 점검했고, 코드는 읽지 않았어요. 해당하지 않는 항목은 개수에서 뺐어요. · 2026년 11월 7일 점검
- ✓ 통과
제작자와 저장소 일치
레지스트리 이름이 GitHub 계정 heliograph-io 기준으로 확인되었고, 이 계정이 저장소를 소유하고 있어요
- … 아직 점검 안 함
계속 관리되고 있음
아직 GitHub에서 이 저장소를 읽어 오지 않았어요
- … 아직 점검 안 함
라이선스 있음
아직 GitHub에서 이 저장소를 읽어 오지 않았어요
- – 해당 없음
엔드포인트 응답
내 컴퓨터에서 실행되는 서버라 인터넷 엔드포인트가 없어요
- – 해당 없음
OAuth로 로그인
내 컴퓨터에서 실행되며, 대신 로컬 설정을 사용해요
- … 아직 점검 안 함
도구 설명에 숨겨진 지시 없음
내 컴퓨터에서 실행돼요. 도구 목록은 인터넷 엔드포인트가 있는 서버에서만 읽을 수 있어요
개발자 도구 카테고리의 다른 서버와 비교i
- 이 카테고리의 다른 서버 4904개 중 0%보다 스타가 많아요
- 이 카테고리의 다른 서버 4904개 중 47%보다 최근에 레지스트리에 공개됐어요
- 기본 점검 결과가 이 카테고리의 다른 서버 4904개 중 100%와 같거나 더 좋아요
레지스트리에서 이 카테고리의 활성 서버 전체와 비교했어요. 스타는 게시자가 저장소를 소유한 경우에만 세요.
자주 묻는 질문
Heliograph, 안전한가요?
해당하는 기본 점검 1개 중 1개를 통과했어요. 코드는 읽지 않았어요. 키나 토큰을 넣기 전에 서버가 어떤 권한을 요구하는지 확인하고, 꼭 필요한 권한만 있는 키를 쓰세요.
어떤 키나 코드가 필요한가요?
레지스트리에 필수 키가 나와 있지 않아요. 다만 처음 쓸 때 로그인을 요구하는 서버도 있어요.
내 컴퓨터에서 실행되나요, 클라우드에서 실행되나요?
내 컴퓨터에서 실행돼요. AI 앱이 필요할 때 실행하고, 데이터는 제작자의 서버를 거치지 않아요(서버 자체가 온라인 서비스를 호출하는 경우는 제외).
아직 관리되고 있나요?
GitHub 저장소는 마지막으로 – 변경됐고, 최신 버전(0.4.3)은 2개월 전 레지스트리에 올라왔어요.
어떤 앱에서 쓸 수 있나요?
Claude Desktop, Claude Code, Cursor, VS Code처럼 MCP를 지원하는 앱에서 쓸 수 있어요. 내 컴퓨터에 Node.js도 있어야 해요.
대신 쓸 수 있는 건 뭐가 있나요?
같은 카테고리에는: GitHub, Desktop Commander, Cloudflare MCP
대안
같은 카테고리에서 다른 제작자가 만든 서버예요. 스타 순으로 정렬했어요.
카드 보는 법:★ GitHub 스타i세 기둥: 리뷰 · 점검 · 사용 정도i업데이트 = 최신 버전을 레지스트리에 공개한 날i
Desktop Commander
제작자: wonderwhy-er
MCP server for terminal commands, file operations, and process management
내 컴퓨터에서 실행★ 10,225MIT16일 전 업데이트
설치
Cloudflare MCP
제작자: cloudflare
Cloudflare MCP servers
클라우드에서 실행★ 4,446Apache-2.014개월 전 업데이트
설치
제작자의 README
README 열기
제작자의 저장소에서 쓰인 그대로 가져왔어요. PopNx MCP가 검토하거나 보증한 내용이 아니에요. HTML, 이미지, 스크립트는 제거했어요. 링크를 누르면 이 사이트를 벗어나요.
heliograph
Remote, captured, auditable execution on a machine you cannot log into
A free, open-source tool by DBHQ
Someone can reach the machine. You cannot, and you are the one who knows what to ask it. heliograph runs that gap as a loop rather than a relay: you publish a step, it runs on the far side, and the whole run comes back as a log with every line timestamped in UTC, whether it passed or failed.
you heliograph send net-probe ────────────────▶ transportstation picks it up within seconds, runs it pushes status, then the log ──────────────▶ transport you heliograph logs --last --gaps ◀────────────
The three ways across
heliograph carries a request to a machine you cannot log into, and brings the log back. There are three ways across the gap, and they differ in one thing: what stays held, and for how long.
Beacon. You cannot reach the machine and it cannot reach you - but you can both reach one agreed place. You leave the request there and walk away. Later the machine passes by, picks it up, runs it, and leaves the log for you to collect. Nobody is ever connected; a *message* waits in the middle. It is the safest of the three, because the code being run is already on the far side and can be read before anything happens - and the slowest, because you wait for the next visit.
Flare. You can reach the machine's door directly. You knock, hand over the request, wait on the step while it runs, and take the log away in the same visit. Nothing waits in the middle and no line stays open. Faster, because there is no pickup to wait for. The trade: you bring the code with you, so the machine trusts *the door* rather than vetting the code in advance.
Beam. You and the machine bring up a connection and hold it open. Either side can speak at any moment and the other hears it at once, until you hang up. A real session, not a message or a knock - and the most exposed, because while the line is open anything can travel down it. You turn it on deliberately and close it when you are done. It is designed, and not yet a transport you can pick.
In one line: a beacon holds a *message*, a flare is a *single exchange*, a beam holds the *connection itself*.
Does this sound familiar
- You have no SSH access to production, and you are not going to be given any.
- The environment is air-gapped, or behind a bastion, a jump host or a VPN you are not on.
- It is a client-owned or customer-managed estate. Only their staff can log in.
- Access is blocked by policy, not capability: restricted, change-controlled, somebody else's sign-off.
- You are on the fourth round of "can you run this and paste the output", and what came back was a screenshot of half a terminal.
- You are an AI coding agent driving an investigation, and you need the evidence rather than somebody's summary of it.
If you can just SSH in, you do not need this.
Three roles, one boundary
The boundary is the gap, and the layout states it once:
| control | your machine: the heliograph CLI, heliograph mcp, and the skill that drives them. Go, and whatever the near side can afford |
| transport | the channel: git, relay, file share, bundle, object store - all behind one interface, so the read-only gates live in one place and cannot drift per transport |
| station | the far side: station/bash/, planted into a private transport repo. Bash 4+, git and GNU coreutils. No packages, no credentials, no tunnel |
Nothing is ever installed on the far side. The station is plain text you can read before you run - bash 4+, or PowerShell 5.1 for a Windows estate that has no bash and will not be given any - and no Go will ever appear under station/ beyond the one file that lets the CLI carry the payload. CI enforces it. That constraint is the entire proposition on a locked-down box where installing anything is its own change request.
Install
# Linux and macOS, from a releasecurl -sSL https://github.com/heliograph-io/heliograph/releases/latest/download/heliograph-linux-amd64 \ -o /usr/local/bin/heliograph && chmod +x /usr/local/bin/heliograph
or from source
go install github.com/heliograph-io/heliograph/cmd/heliograph@latest
A single static binary, no runtime. Checksums are published with each release, and the binary carries the station payload it was built with.
The build is reproducible: packaging/reproduce.sh v0.4.3 rebuilds every released artefact from the tag and arrives at the published hashes, so "the binary in the path is the source you read" is something you check rather than something we say. Full account, including what is not yet covered, at docs.heliograph.io/provenance.
The agent skill - the same loop, driven from Claude Code, Codex, Cursor and friends:
/plugin marketplace add dbhq-uk/marketplace/plugin install heliograph@dbhq # Claude Code ./install-codex.sh # Codex, from a clone ./install.sh # Claude Code, from a clone npx skills add heliograph-io/heliograph # any agent, via skills.sh
Use
heliograph bootstrap ~/transport/payments # plant the station payloadheliograph init payments --dir ~/transport/payments # git, the default heliograph plant # what to send the operator heliograph send net-probe HOSTS="sql01 sql02" # publish a request heliograph watch # follow it heliograph logs --last # read the whole log heliograph logs --last --gaps # where it stalled heliograph doctor # will this work from here heliograph mcp # serve all of the above as tools
The operator's whole job is what plant prints: clone the transport repo, run ./start.sh, walk away. The loop is read-only unless the operator said otherwise: every step declares itself (# heliograph-mode: read-only or action), one that declares neither does not run, and the station refuses an action unless it was started with --allow-actions. It will not run as root either.
For an agent, heliograph mcp is the same CLI as typed MCP tools:
claude mcp add heliograph -- heliograph mcpThe gates do not move. A tool call publishes a request; the station still decides whether to run it.
--gaps is the one worth knowing about. *"Scan the timestamp column for gaps before reading the content"* is the most valuable instruction in the method, and it is arithmetic:
$ heliograph logs --last --gapsdemo-20260906T183628Z.txt 5 captured lines
1 interval(s) of 10s or more, longest first. Each is attributed to the line BEFORE it, which is what was running.
3m12s after 09:14:02 | Refreshing state...
The gap belongs to the line before it: the stamp on a line is when that line was produced, so a long interval means the operation named on the preceding line is what took the time. A log where every line carries the same timestamp is reported as an error, not as "no gaps".
Status
| control CLI over git | works, tested end to end against a stock station |
heliograph bootstrap | works: the binary plants the station it was built with |
--gaps | works |
MCP server (heliograph mcp) | works |
| bash station | in use over git: the loop, the gates, the capture, Azure hosts, Kubernetes, the Windows launcher |
| relay | works end to end. heliograph init --transport relay selects it, both stations implement it, the relay server is deployed, and TestCLIDrivesARelayStation drives the whole loop in CI |
| file share, bundle, object store | station transports exist for all three in the bash station (station/bash/transports/); init selects share, bundle and objstore. The PowerShell station carries share but not bundle or objstore |
| Azure Blob | works end to end, through drop.sh in the station payload rather than the CLI. It is what the Azure Function host uses |
| PowerShell station | ships. station/powershell/ is ~2,600 lines carrying git, share and relay, and CI runs it on a Windows runner. Design: A8 |
| documentation site | docs.heliograph.io: the CLI, the transports, and the far side - the station, the runner, steps, hosts, Azure, Windows, containers, services, secrets, security and the capture contract |
A transport that works on one side of the gap is not a transport, so this table names both sides. Git and relay are driven end to end by the CLI and proved in CI; what the others still need, and in what order, is the roadmap.
This table was wrong for some time, and the reason is worth keeping. Until
21 Sep 2026 it said relay was "half a transport" that "no CLI command can
select", that the station had no transport for share, bundle or object store,
and that the PowerShell station was "planned". All four were false against the
code in this repository. The documentation site did not drift, because
transports_doc_test.gobinds it toinitTransportsand to the station
transport directories - and nothing bound this file. It is bound now, by
TestReadmeTransportClaimsMatchTheCode.
The cost was not confined here:
skills.dbhq.uk/heliographdeliberately
published the *more conservative* claim because this README contradicted the
documentation site, and recorded that it would stay understated "until
heliograph settles which is true". This is that settlement.
The relay
Both sides dial out over ordinary HTTPS, so an estate needs no git host, no storage account and no VNet. Hosted, and self-hostable from the same binary.
Not yet usable end to end. The station side is complete and the server is deployed; no CLI command can select it, so the near side is the missing half.
The relay cannot read your logs, and cannot make a station run anything. That second half is the one that matters: a relay able to forge a request would be code execution inside every estate at once. Content is end-to-end encrypted with keys the relay never holds, and every message is signed. Nothing bespoke - age primitives plus Ed25519. The full account, including what DBHQ can and cannot honestly claim, is in docs/specs/2026-09-06-relay-encryption-design.md. The relay server is its own repository, heliograph-io/heliograph-relay, because it holds no keys and must be publicly, obviously incapable of reading anything it carries.
What the beam is, and what it costs
The beam is designed and not yet built; what follows is what it will do when it lands.
Two of the three shapes never hold a connection open. A beacon leaves a message where both sides can reach it, and needs nothing to be reachable, ever - no inbound port, no endpoint, no tunnel. A flare knocks, waits and leaves; what it does not do is hold the line open once the answer is back, and between the two of them an estate that will not have a held-open line at all still gets the whole job done.
The beam does hold a line open, live and two-way, and that is a tunnel. A blue team will read a held-open channel as one, because it is one. So it is **off unle
앞부분만 보여 드려요. 나머지는 저장소에서 읽어 보세요