SquidCI

SquidCI is CI/CD for GitHub repositories whose builds run in your own AWS account. A repository describes what to build, test, publish and deploy in one file, .squidci/pipelines.yaml. SquidCI reads it on every push and pull request, runs the jobs on workers in your account, reports them to GitHub as checks, and deploys each version through your environments in order.

Your code is cloned in your account and your builds’ secrets stay there. SquidCI holds neither.

Start here

• Getting started: connect GitHub and an AWS account, then run your first pipeline. About fifteen minutes.
• Set up with a coding agent: prompts to hand Claude Code or another agent, so it writes the pipeline file for you.
• The pipeline file: how to describe your builds, then every setting.

How it fits together

• Your organization signs in at squidci.app and connects two things: a GitHub account, through the SquidCI GitHub App, and an AWS account, by creating a CloudFormation stack there.
• The stack is your execution plane. It holds worker groups — EC2 instances, or Lambda functions — that ask SquidCI for work and run it. No inbound access to your account is opened.
• A push to a repository’s default branch runs its pipeline: checks, tests and builds at once, then what publishes and deploys. A pull request runs its checks, tests and builds only, with no AWS access.
• Deploys go to environments, each with its own AWS access, in the order you declare. They happen every version, on a schedule, or by hand from the deploy page.

For agents

Every page here is Markdown at its own URL plus .md, and /llms.txt lists them all. The pipeline file has a JSON Schema at squidci.com/schema/pipelines.json to check a file against before pushing it.