● pico.sh

538 2026-08-14 note ♂︎ ☿︎

pico.sh is an SSH-powered hosting platform that deploys static sites with a single rsync command. The workflow is radically simpler than GitLab Pages or Netlify: no CI/CD configuration, no dashboards, no build pipelines. Your SSH key is your identity, and projects are created on first upload.

Deployment Comparison

pico.sh: rsync -rv ./public/ pgs.sh:/mysite/ is the single command, and it deploys instantly. Projects are upserted on file upload, TLS certificates are automatic, and rollbacks happen via symbolic links. It uses commands like rsync, scp, sftp, sshfs. https://pico.sh/pgs

GitLab Pages: Requires a .gitlab-ci.yml file with a pages job, builds run on GitLab runners, deploys from a public/ folder. Integrated with Git workflow but more setup overhead. Free with GitLab hosting, custom domains with Let's Encrypt. https://docs.gitlab.com/user/project/pages/

Netlify: Git-based deployment with automatic build detection, or drag-and-drop folder upload. Preview URLs for every branch, global CDN, but more complex feature set with serverless functions, databases, auth. Credit-based pricing even for free tier. https://netlify.com/pricing

pico.sh Features

• Free tier: 25MB storage, most features included
• pico+ tier: $2/month billed yearly, 10GB storage, analytics, IRC bouncer https://pico.sh/plus
• Global CDN: Multi-region edge caching
• Custom domains: Simple DNS configuration
• Redirects & rewrites: _redirects file like Netlify
• Custom headers: _headers file for security headers, caching, CORS
• Additional services:
  • tuns.sh for HTTPS/WSS/TCP tunnels to localhost
  • prose for blog platform via SSH
  • pipe for authenticated Unix pipes
  • pastes for code snippets
  • RSS-to-email service
• Open source: https://github.com/picosh/pico/

Trade-offs

pico.sh trades the Git integration and CI/CD sophistication of GitLab Pages and Netlify for raw simplicity. There's no automated build step, you run your 11ty buildA static site generator takes markdown and templates and compiles them into plain HTML files with no server-side code and no database. For a digital garden that's meant to be worked on continuously, the boring reliability is a great asset.… locally, then rsync the output. This is good for something like manuscript workflowThe writerdeck pushes to a private git repo, one commit per session, and the same discipline as this site's own daily-commit habit. Commits are the only telemetry, there's no cloud sync or background daemon watching the manuscript folder. A post-commit… where a post-commit hook already generates the deploy artifact.

The lack of Git integration means no automatic preview URLs per branch, but also no commit-linked deploy history to manage. For a digital gardenA digital garden is a website that grows in public instead of publishing in the finished, dated-post format of a blog. Entries get revised in place, start rough and get filled in over time, and are organized by association rather… that's manually curated rather than branch-heavy, this is a feature, not a bug.

Compared to the obscure Netlify workaroundURLminder needs a public URL, which rules out anything private. The workaround is obscurity. Deploy the rendered manuscript feed to Netlify under a subdomain that's a long random string rather than a chosen name, eg. x7q2m9vb4k1p.netlify.app. No custom domain, no…, pico.sh would be even simpler for the URLminder use case, no Netlify account, no netlify deploy --prod, just rsync the rendered file directly. The trade is giving up Netlify's dashboard and deploy history for SSH-native simplicity.