Commit 79ac008
Eric Bower
·
2026-05-19 21:00:56 -0400 EDT
parent 766f8b9
docs: site copy
1 files changed,
+39,
-83
+39,
-83
1@@ -2,7 +2,9 @@
2 <html lang="en">
3 <head>
4 <meta charset="UTF-8">
5-<meta name="viewport" content="width=device-width, initial-scale=1.0">
6+<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">
7+<meta name="apple-mobile-web-app-capable" content="yes">
8+<meta name="apple-mobile-web-app-status-bar-style" content="black">
9 <title>pici – Your Build Isn't a Log. It's a Terminal.</title>
10 <style>
11 /* ============================================================
12@@ -76,9 +78,9 @@ section {
13 ============================================================ */
14
15 nav {
16+ z-index: 1;
17 position: sticky;
18 top: 0;
19- z-index: 100;
20 background: var(--bg-deep);
21 border-bottom: 1px solid var(--surface);
22 padding: 0.75rem 0;
23@@ -113,7 +115,7 @@ nav ul {
24
25 nav ul a {
26 color: var(--text-dim);
27- font-size: 0.85rem;
28+ font-size: 0.7rem;
29 text-transform: uppercase;
30 letter-spacing: 0.05em;
31 }
32@@ -615,7 +617,7 @@ details .faq-answer {
33 You re-run the job and wait 10 minutes to find out you were wrong. Repeat.
34 </p>
35 <p>
36- Debugging CI should not be an archaeological dig through log files in a browser.
37+ Debugging CI shouldn't require you to guess what happened.
38 </p>
39 </div>
40 <div class="terminal">
41@@ -648,23 +650,17 @@ details .faq-answer {
42 <section id="how">
43 <div class="container">
44 <p class="section-label">The Solution</p>
45- <h2>Jump into your failing build.</h2>
46+ <h2>Attach to your failing build.</h2>
47 <div class="two-col">
48 <div>
49 <p>
50 Every build step in <code>pici</code> runs as a <strong>real terminal session</strong>: a PTY you can attach to.
51- No "enable debugging" flag. No "re-run with SSH" button. No waiting for a tunnel.
52+ No "enable debugging" or "re-run with SSH" buttons.
53 </p>
54 <p>
55 A test fails? Attach to the session, press <code>↑</code> + <code>Enter</code> to rerun the command,
56- inspect the environment, fix the issue. You're already there.
57+ inspect the environment, and fix the issue before trying again.
58 </p>
59- <ul class="check-list">
60- <li><code>zmx attach ci.myrepo.test</code> to jump in</li>
61- <li>Press <code>↑</code> to rerun the failing command</li>
62- <li>Inspect files, env vars, network state</li>
63- <li>No debug mode. It's just a terminal.</li>
64- </ul>
65 </div>
66 <div>
67 <div class="terminal">
68@@ -706,7 +702,7 @@ details .faq-answer {
69 <section id="engine">
70 <div class="container">
71 <p class="section-label">Job Engine</p>
72- <h2>Parallel tasks. Zero config. Same commands everywhere.</h2>
73+ <h2>Parallel tasks, zero config, and zero install.</h2>
74 <div class="two-col">
75 <div class="terminal">
76 <div class="terminal-bar">
77@@ -719,17 +715,18 @@ details .faq-answer {
78 <div><span class="comment">#!/usr/bin/env bash</span></div>
79 <div><span class="cmd">set -euo pipefail</span></div>
80 <div> </div>
81- <div><span class="comment"># These run in parallel, no config needed</span></div>
82+ <div><span class="comment"># This step runs until it's finished</span></div>
83 <div><span class="cmd">zmx run lint docker run golangci-lint run</span></div>
84- <div><span class="info"> → started session: ci.myrepo.lint</span></div>
85+ <div><span class="info"> → No issues found!</span></div>
86 <div> </div>
87- <div><span class="cmd">zmx run test go test ./...</span></div>
88+ <div><span class="comment"># These run in parallel</span></div>
89+ <div><span class="cmd">zmx run test -d go test ./...</span></div>
90 <div><span class="info"> → started session: ci.myrepo.test</span></div>
91 <div> </div>
92- <div><span class="cmd">zmx run build go build -o bin/pici .</span></div>
93+ <div><span class="cmd">zmx run build -d go build -o bin/pici .</span></div>
94 <div><span class="info"> → started session: ci.myrepo.build</span></div>
95 <div> </div>
96- <div><span class="comment"># Wait for all to finish</span></div>
97+ <div><span class="comment"># Wait for all tasks to finish</span></div>
98 <div><span class="cmd">zmx wait "*"</span></div>
99 <div> </div>
100 <div><span class="comment"># Runs identically locally and in CI</span></div>
101@@ -738,18 +735,19 @@ details .faq-answer {
102 <div>
103 <p>
104 Your pipeline is <code>pico.sh</code>: a bash script that runs <strong>identically on your machine
105- and on the CI runner</strong>. No YAML, no DSL, no "it works on my machine" gap.
106+ and on the CI runner</strong>; no yaml required.
107 </p>
108 <p>
109 <a href="https://zmx.sh"><strong>zmx</strong></a> is the job engine. Each <code>zmx run</code> spawns
110 a parallel terminal session. <code>zmx wait "*"</code> blocks until they all finish.
111- Run tasks sequentially by just calling them one after another, or in parallel; it's bash,
112- you control the flow.
113+ Run tasks sequentially by just calling them one after another, or in parallel by using the
114+ detach (<code>-d</code>) flag.
115 </p>
116 <ul class="check-list">
117 <li>Same <code>zmx run</code> commands locally and in CI</li>
118- <li>Parallel by default, sequential when you want it</li>
119+ <li>Sequential by default, parallel when you want it</li>
120 <li>Every step is an attachable terminal session</li>
121+ <li>Bring your own isolation: use docker in your step commands</li>
122 <li>No YAML matrices, no <code>run: parallel</code> keywords</li>
123 </ul>
124 </div>
125@@ -774,15 +772,6 @@ details .faq-answer {
126 Git post-receive hooks are just one trigger. You can fire builds from anything:
127 a cron job, a file watcher, a webhook receiver on your own server, a button press.
128 </p>
129- <div class="flow">
130- <div class="node">rsync workspace</div>
131- <div class="arrow">→</div>
132- <div class="node">ssh pub event</div>
133- <div class="arrow">→</div>
134- <div class="node">pico.sh runs</div>
135- <div class="arrow">→</div>
136- <div class="node">artifacts synced</div>
137- </div>
138 </div>
139 <div>
140 <img src="flow.png" style="width: 100%; border-radius: 10px;" />
141@@ -806,7 +795,7 @@ details .faq-answer {
142 </p>
143 <p>
144 The managed service runs on our own hardware, not a cloud provider. Self-hosted
145- is coming once the source is ready.
146+ is coming once the runner is ready.
147 </p>
148 <ul class="check-list">
149 <li>SSH keys are your auth</li>
150@@ -867,12 +856,12 @@ details .faq-answer {
151 <div>
152 <p>
153 <strong>ci.pico.sh</strong> runs on <a href="https://cd.pico.sh"><strong>cd.pico.sh</strong></a>: our SSH VM service
154- on hardware we own. Not AWS. Not GCP. Not a cloud provider.
155+ on hardware we own.
156 </p>
157 <p>
158 Push a <code>docker-compose.yml</code> to an SSH endpoint and your containers are live.
159- Label a service and it gets a public HTTP URL. No cloud console, no CLI SDK,
160- no provider lock-in.
161+ Label a service and it gets a public HTTP URL. There's no provider lock-in because it's a tool
162+ you likely already use for local development.
163 </p>
164 <p>
165 The same platform that runs your CI runs your apps.
166@@ -924,38 +913,39 @@ details .faq-answer {
167 <section id="features">
168 <div class="container">
169 <p class="section-label">Features</p>
170- <h2>Built for terminals, agents, and humans.</h2>
171+ <h2>Built for terminals, humans, and automation</h2>
172 <div class="feature-grid">
173 <div class="feature-card">
174- <h3>AI-Agent Friendly</h3>
175+ <h3>Terminal Friendly</h3>
176 <p>
177- Terminal workflows, rsync + SSH pubsub, JSONL status streams. Everything an agent
178- needs to trigger builds, monitor progress, and attach to failures. No OAuth flows,
179- no API rate limits, no webhooks. An agent can start as many jobs as it wants
180- and read results as structured text.
181+ Because <code>pici</code> doesn't rely on git-ops and triggering a
182+ build is done with rsync + ssh, we have the building blocks for you
183+ or a code agent to trigger builds, monitor progress, and attach to
184+ failures. Start as many jobs as you need and read results
185+ synchronously.
186 </p>
187 </div>
188 <div class="feature-card">
189 <h3>SSH-First</h3>
190 <p>
191- No HTTP APIs to expose. No webhooks to configure. No OAuth tokens to manage.
192- SSH keys are your auth. SSH pubsub is your event bus.
193- If SSH works, CI works.
194+ SSH keys are your auth and we even support using SSH certificates for RBAC control.
195+ Rsync to upload workspaces, build artifacts, and ssh pubsub as your event bus.
196 </p>
197 </div>
198 <div class="feature-card">
199 <h3>Static Site Artifacts</h3>
200 <p>
201- Build artifacts are plain HTML + CSS. No JavaScript. No app server. No build step.
202- Serve the directory with any static host: nginx, s3, pgs.sh, <code>python -m http.server</code>.
203- Zero runtime dependencies.
204+ Build artifacts are plain HTML + CSS. There's no app server or build step.
205+ Serve the directory with any static host: nginx, s3, <a href="https://pgs.sh">pgs.sh</a>,
206+ <code>python -m http.server</code>.
207+ It's a static site with zero runtime dependencies.
208 </p>
209 </div>
210 <div class="feature-card">
211 <h3>Build Attestation</h3>
212 <p>
213 Automatic provenance baked into every job: runner hostname, OS, arch, repo, branch,
214- commit, and workspace checksum. Supply-chain ready without extra tooling.
215+ commit, and workspace checksum.
216 </p>
217 </div>
218 </div>
219@@ -1052,18 +1042,6 @@ details .faq-answer {
220 </div>
221 </details>
222
223- <details>
224- <summary>How is this different from GitHub Actions, Jenkins, etc.?</summary>
225- <div class="faq-answer">
226- <p>
227- Every build step in <code>pici</code> runs as a real terminal session (PTY) you can attach to.
228- No "re-run with SSH" button, no waiting for a tunnel. A test fails? Jump into the session,
229- press <code>↑</code> + <code>Enter</code> to rerun the command, inspect the environment,
230- fix the issue. Your pipeline is a bash script, same commands locally and in CI.
231- </p>
232- </div>
233- </details>
234-
235 <details>
236 <summary>How much does it cost?</summary>
237 <div class="faq-answer">
238@@ -1084,28 +1062,6 @@ details .faq-answer {
239 </p>
240 </div>
241 </details>
242-
243- <details>
244- <summary>How do I trigger builds?</summary>
245- <div class="faq-answer">
246- <p>
247- Publish an event to <code>pipe.pico.sh</code> on the <code>build.event</code> channel with a
248- JSON payload containing the event type and workspace. Git post-receive hooks are the common
249- pattern, but anything that can SSH can trigger a build: cron, webhooks, file watchers, a button press.
250- </p>
251- </div>
252- </details>
253-
254- <details>
255- <summary>Can I use my own runners?</summary>
256- <div class="faq-answer">
257- <p>
258- Yes, it's a first-class citizen. Bring your own hardware, your own isolation strategy: docker,
259- namespaces, bare metal. The same <code>pico.sh</code> and <code>zmx</code> sessions work
260- identically whether you run on your infra or ours.
261- </p>
262- </div>
263- </details>
264 </div>
265 </section>
266