The Problem
A build fails. You scroll through 2,000 lines of log output. You guess what went wrong. You re-run the job and wait 10 minutes to find out you were wrong. Repeat.
Debugging CI shouldn't require you to guess what happened.
The Solution
Every build step in pici runs as a real terminal session: a PTY you can attach to.
No "enable debugging" or "re-run with SSH" buttons.
A test fails? Attach to the session, press ↑ + Enter to rerun the command,
inspect the environment, and fix the issue before trying again.
Job Engine
Your pipeline is pico.sh: a bash script that runs identically on your machine
and on the CI runner; no yaml required.
zmx is the job engine. Each zmx run spawns
a parallel terminal session. zmx wait "*" blocks until they all finish.
Run tasks sequentially by just calling them one after another, or in parallel by using the
detach (-d) flag.
zmx run commands locally and in CIrun: parallel keywordsTrigger Model
Most CI systems are glued to Git webhooks. pici isn't. The core loop is simple:
rsync a workspace and publish an event over SSH.
Git post-receive hooks are just one trigger. You can fire builds from anything: a cron job, a file watcher, a webhook receiver on your own server, a button press.
Managed Service
Trigger builds by publishing events over SSH. Your pipeline runs as real terminal sessions you can attach to. No web console, no API keys, no OAuth.
The managed service runs on our own hardware, not a cloud provider. Self-hosted is coming once the runner is ready.
Who It's For
pici is built for individuals and small teams who want to move fast. You write a bash
script, you push your code, your build runs, and if something breaks you jump into the
terminal and fix it. No YAML labyrinths, no approval workflows, no complex pipeline DAGs.
We're not building marketplace integrations, compliance reports, or workflow bureaucracy. What you will find is the CI system you'd write for yourself.
Infrastructure
ci.pico.sh runs on cd.pico.sh: our SSH VM service on hardware we own.
Push a docker-compose.yml to an SSH endpoint and your containers are live.
Label a service and it gets a public HTTP URL. There's no provider lock-in because it's a tool
you likely already use for local development.
The same platform that runs your CI runs your apps.
git pushFeatures
Because pici doesn't rely on git-ops and triggering a
build is done with rsync + ssh, we have the building blocks for you
or a code agent to trigger builds, monitor progress, and attach to
failures. Start as many jobs as you need and read results
synchronously.
SSH keys are your auth and we even support using SSH certificates for RBAC control. Rsync to upload workspaces, build artifacts, and ssh pubsub as your event bus.
Build artifacts are plain HTML + CSS. There's no app server or build step.
Serve the directory with any static host: nginx, s3, pgs.sh,
python -m http.server.
It's a static site with zero runtime dependencies.
Automatic provenance baked into every job: runner hostname, OS, arch, repo, branch, commit, and workspace checksum.
Comparison
piciFAQ
It's coming. pici is still in early development and not yet ready for public
review. We'll open-source everything when the API, runner, and tooling are stable enough
to be useful. Sign up for the beta below to get notified.
Yes, self-hosting is a core goal. Once the source is released you'll be able to run
pici on your own infra with your own isolation strategy: docker, namespaces,
bare metal. You choose.
pici.
We're opening the managed beta at ci.pico.sh.
No spam. We'll email you when beta slots open.