name: mydevops
description: mydevops is a personal DevOps CLI that orchestrates provisioning,
server configuration, and application deployment across arbitrary
infrastructure — VPS providers (Hetzner, OVH, AWS, Azure, GCP, DigitalOcean,
Scaleway, Linode, Alibaba, Proxmox, vSphere), Docker, and Kubernetes (EKS or
self-hosted). A single mydevops.yml file per project drives the whole
pipeline: provisioning, server config, build, deploy, SSL, monitoring,
backups, and CI/CD generation. It is a thin orchestration layer over
pre-installed system tools (docker, git, ssh, terraform, ansible, kubectl,
rsync…) — none of these are bundled in the snap; mydevops just shells out to
whichever ones the user already has.
snapcraft: https://github.com/Ronaldo-F-dev/mydevops/blob/main/snapcraft.yaml
upstream: https://github.com/Ronaldo-F-dev/mydevops
upstream-relation: I am the sole author and maintainer of the upstream project.
supported-category: public cloud agents
reasoning: mydevops orchestrates deployment and provisioning against multiple public cloud providers (AWS, GCP, Azure, Hetzner, OVH, DigitalOcean, Scaleway, Linode, Alibaba) plus Kubernetes (EKS or self-hosted) and arbitrary Docker hosts, by shelling out to each provider’s own CLI/SDK-backed tooling (terraform, ansible, kubectl, aws/az/gcloud where relevant) and to git/ssh for deploying to the user’s own servers. That requires the same class of broad, statically-unknowable filesystem access that justifies classic for the cloud provider CLIs themselves (aws-cli, google-cloud-sdk, azure-cli):
- Cloud provider credentials/config in their standard per-provider locations (~/.aws/, ~/.config/gcloud/, Terraform state and provider caches, etc.), read by the tools mydevops shells out to on the user’s behalf.
- SSH private keys anywhere under the user’s home (~/.ssh/ or a path the user names in mydevops.yml) used to connect to the user’s own deployed servers.
- Arbitrary project directories: mydevops is invoked from wherever the user’s project lives — there is no fixed location to scope access to, and it writes generated artifacts (Dockerfiles, CI pipelines, Terraform modules, Ansible playbooks) directly into that project tree.
None of these paths are knowable at snap build time — they’re determined per-invocation by the user’s own project layout and by which cloud provider(s)/servers a given mydevops.yml targets.
I understand that strict confinement is generally preferred over classic.
I’ve tried the existing interfaces to make the snap work under strict
confinement: home only covers $HOME itself, not arbitrary project
directories mounted or checked out elsewhere; ssh-keys covers ~/.ssh but
not a user-specified key path from mydevops.yml, nor the cloud-provider
config directories above; personal-files/system-files require
enumerating exact paths in advance, which doesn’t work here since the
paths (project directory, SSH key location, which cloud provider’s config
directory is relevant) are chosen by the user’s own config file at runtime,
not fixed at build time.
