Galleon
Sign In

GitHub Integration

GitHub is the foundation Galleon runs on. Authentication, repository access, CI/CD execution, and automated fixes all happen through your GitHub account. Galleon doesn't run a parallel auth system, doesn't host your code, and doesn't execute your builds — everything that touches your application stays inside systems you already control.

Authentication

You sign in to Galleon with your GitHub account via OAuth. There is no separate Galleon username or password — no Galleon credential to leak, no password reset flow, no MFA to configure separately. Your GitHub identity determines which repositories and projects you can access.

Repository access

When you connect a repository to Galleon, the integration requests:

  • Read access to repository contents and metadata, so Galleon can scan your file tree, detect frameworks, and read configuration files.
  • Write access to commit generated Terraform files, GitHub Actions workflows, and Dockerfiles to your repository.
  • Pull request access to open fix PRs when deployments fail.
  • Workflow access to trigger and read GitHub Actions runs.

You can revoke Galleon's access from your GitHub settings at any time. If you do, Galleon stops working for that repo, but the Terraform files, workflow, and any deployed infrastructure remain in your account — they're yours.

Galleon never receives access to repositories you haven't explicitly connected.

Framework auto-detection

When you connect a repo, Galleon scans the file tree to identify your application:

  • package.json — Node.js applications (Next.js, Express, etc.)
  • requirements.txt or pyproject.toml — Python applications (Django, FastAPI)
  • Dockerfile — pre-containerized applications
  • next.config.js / next.config.ts — Next.js specifically

Monorepos are supported. Galleon scans common directory conventions (apps/, packages/, services/) and detects multiple applications within a single repository. Each detected application gets its own deployment configuration.

CI/CD via GitHub Actions

Galleon does not run builds or deployments on its own servers. Your code never executes on infrastructure controlled by Galleon.

Instead, Galleon generates a GitHub Actions workflow and commits it to your repository. The workflow runs on GitHub-hosted runners — or your self-hosted runners, if you've configured them — and handles:

  • Building your application — Docker image for container deployments, or OpenNext bundle for serverless Next.js.
  • Running Terraform — terraform init, plan, and apply to provision or update AWS infrastructure.
  • Deploying your application — pushing the built artifact to ECS, Lambda, S3, or other AWS services.
  • Authenticating to AWS via OIDC — assuming a scoped IAM role using GitHub's OIDC provider.

The workflow file lives in .github/workflows/galleon-deploy-{app-name}.yml in your repository. You can inspect it, customize it, or extend it as needed. Once the initial deployment succeeds, the workflow runs automatically on every push to main.

Fix PRs

When a deployment fails, Galleon reads the GitHub Actions logs, diagnoses the root cause using AI failure analysis, and — for issues in your infrastructure or configuration — opens a pull request with the fix.

What this looks like in practice:

  • Your deploy fails because the container's health check expects port 3000 but your app listens on 8080. Galleon detects the mismatch in the Terraform task definition and opens a PR with the corrected port.
  • Your deploy fails because the IAM role can't pull from ECR. Galleon identifies the missing permission and opens a PR adding it to the role policy.
  • Your deploy fails because an environment variable Galleon expected isn't set. Galleon flags the missing variable and opens a PR with a placeholder for you to fill in.

Each fix PR includes a description of what failed, the relevant log lines, the proposed change, and the reasoning. You review and merge it like any other PR. When you merge, the workflow redeploys automatically.

Fix PRs cover infrastructure and configuration issues. For application-code failures — unhandled exceptions, dependency errors, broken tests — Galleon surfaces the diagnosis with the specific log lines and suggested fix in the deployment UI, but doesn't modify your application code.

See AI Failure Analysis for the full list of failure patterns Galleon recognises.

Security model

Galleon's GitHub and AWS integrations are designed so that no long-lived secrets cross any system boundary.

  • OIDC federation for AWS access. GitHub Actions assumes an IAM role in your AWS account via OpenID Connect — a short-lived token exchange, not stored credentials. No AWS access keys exist in your repository, in GitHub secrets, or in Galleon's database. There's nothing to leak because there's no static credential in the first place.
  • Scoped IAM role. The IAM role GitHub Actions assumes is scoped to the specific permissions Galleon's deployments need. It's created in your AWS account via a CloudFormation template during onboarding, and you can audit or modify it at any time.
  • Cross-account isolation. Each AWS connection uses a unique ExternalId to prevent confused deputy attacks. The role's trust policy restricts assumption to your specific GitHub repository — another repo, even one you also own, cannot assume the role.
  • Galleon never executes your code. Your build runs on GitHub-hosted (or self-hosted) runners. Your deployment runs in your AWS account. Galleon orchestrates and observes, but never executes.

Next steps