[git push]
Add a git remote and push your repo. picd builds your container images and deploys the stack automatically.
$ git push picd main
Git-push deployments powered by Docker Compose. Manage everything over SSH.
Push a repository with a compose file to a dedicated Docker engine in your own VM. Automated HTTPS, custom domains, and complete control over SSH. All you need is git and ssh.
[projects]
Users have access to projects, each with its own compose file to deploy and network related services together.
[compose]
Your existing docker-compose.yml is your infrastructure. Native compose runtime with auto-TLS, volume persistence, and ingress routing.
[ssh first]
Status checks, env vars, custom domains, container exec, logs, and attach. Zero CLI SDKs.
[auto https]
Zero-config TLS. Add Traefik labels and your services receive automatic wildcard or custom domain certificates.
[zero-downtime]
New containers start before old ones stop. Your applications stay live during every deploy.
[lazydocker]
Pre-loaded interactive terminal UI for inspecting containers, resources, and logs in your shell.
Deploying shouldn't require a CLI SDK
You have a docker-compose.yml that works locally. To deploy it, you need to click-ops through provisioning a VM and installing docker with proper permissions.
This is the disappearing infrastructure: if it runs on your machine, it runs on picd.
Deploying without picd
# Provision cloud VM
# Install Docker & docker-compose
# Configure Traefik / Caddy & TLS certs
# Set up SSH keys & rsync compose file
# SSH in and run docker-compose up
# Debug via web console (9 steps!)
With picd: Add remote and git push. Stay in your terminal.
Projects & multi-service stacks
Users have access to projects, and each project has its own docker-compose file. All related services for your application (e.g. web apps, background workers, databases, and caches) are declared together and deployed as a cohesive stack.
Services within a project communicate over an isolated private network, sharing volumes and environment variables without leaking into other projects.
Isolated per project
Every project gets its own git remote and SSH namespace:
$ git remote add picd ssh://cd.pico.sh/web.git $ ssh web@cd.pico.sh
Pushing deploys that project's compose file, and SSH access lands directly in your project directory.
git push deploy
Add picd as a git remote and push:
$ git remote add picd ssh://cd.pico.sh/web.git $ git push picd main
picd receives your push, checks out the repo, and runs docker compose up -d. Roll back anytime by pushing an older commit.
Instant deployment feedback
remote: Creating web-web-1 ... done
remote:
To ssh://cd.pico.sh/web.git
95fae00..a34685d main -> main
# your service is now live
Your service is live at https://web-alice.user.cd.pico.sh.
docker compose as infrastructure
Your existing compose file works as-is with Traefik routing:
services:
web:
image: traefik/whoami
labels:
- traefik.enable=true
- traefik.http.routers.web.rule=Host(`web-alice.user.cd.pico.sh`)
networks: [picd-ingress]
networks:
picd-ingress:
external: true
Auto HTTPS and reverse proxying are configured automatically via Traefik labels.
Internal services & persistent volumes
Internal services (like databases) reach each other on the default network without needing ingress:
services:
db:
image: postgres:16
volumes:
- ./data:/var/lib/postgresql/data
Relative and named volume mounts preserve your data across deploys.
Manage everything over SSH
No web dashboards or SDKs to install:
$ ssh cd.pico.sh status web $ ssh cd.pico.sh vars set web DATABASE_URL=postgres://... $ ssh cd.pico.sh redeploy web $ ssh cd.pico.sh domains add app.example.org $ ssh cd.pico.sh compose web ps -a
Container exec, logs, attach & TUI
SSH directly into project containers using prefixes:
$ ssh cd.pico.sh logs web -f # follow service logs $ ssh c-web-web-1@cd.pico.sh # exec into container $ ssh a-web-web-1@cd.pico.sh # attach to container $ ssh web@cd.pico.sh # shell + lazydocker
picd is built for us
picd is for developers and small teams who want to deploy fast without cloud provider lock-in. There is no grand vision of becoming the next digitalocean, or raising VC money to scale, we want this to work really well for those of us who simply need to deploy services that stay online.
The core design principle is build what we want and invite others to use it. Read more about pico's design ethos in our rfc-001: radical experimentation
Frequently asked questions
How much does it cost?
$4/mo for 2 vcpu and 2gb mem, billed yearly.
Are there resource limits?
Your plan limits your environment's CPU, memory, and disk. Every project shares your environment's resources. Check your limits and current usage anytime with ssh cd.pico.sh plan.
Where is picd hosted?
Not on a hyperscaler: we have a quarter rack of compute in a colocation in Ann Arbor, Michigan. There are no plans to expand to new locations. When our quarter rack is fully utilized, that's it. That means we have a limited number of seats to offer for picd.
Can I use private Docker registries?
Yes. Private registries are supported through environment variable management. Set your registry credentials on your project via ssh cd.pico.sh vars set, and they are available during container builds.
Are persistent volumes supported?
Yes. Both named volumes and relative bind mounts (e.g. ./data:/var/lib/...) are supported and your data is preserved across deploys.
Can I get a dedicated ipv4 address?
No. picd utilizes our tuns.sh service to route all ipv4 traffic to your services.
Can I get a dedicated ipv6 address?
Yes!
Why create another SSH-to-VM service?
picd is a full container PaaS powered by Docker Compose. We built on our earlier work with pcompose to provide a clean deployment target that feels completely native to the terminal.
Get early access to picd managed hosting
Sign up for our managed beta at cd.pico.sh.
No spam. We'll email you when beta slots open.