Skip to main content
Choose which repositories can run on Celesto and review what your workflows can access. Each job gets a fresh computer, while your GitHub settings and workflow files determine which code runs and which credentials it receives.

​
GitHub App permissions

Install the Celesto CI App on the repositories you want to use. Connecting it requires a Celesto workspace admin and a GitHub account that administers the selected repositories. One installation connects to one Celesto workspace. Review the permissions GitHub presents during installation or an update. Existing installations may need to approve added permissions. Missing organization runner permission blocks new organization runners; missing Checks permission prevents setup-check updates in GitHub. Organization installations use a Celesto runner group restricted to the selected repositories. Keep its access aligned with the App installation. Adding a repository to a runner group alone does not complete Celesto setup for it.

​
Review code before giving it credentials

A GitHub App’s permissions and a workflow’s credentials serve different purposes. Review the job’s GITHUB_TOKEN permissions, referenced secrets, and any credentials created by its steps.
  • Give GITHUB_TOKEN only the permissions each job needs.
  • Use GitHub environment approvals for sensitive deployment credentials.
  • Review changes to workflow files and third-party actions before running them with secrets.
  • Keep credentials out of dependency caches, uploaded artifacts, and printed output.
See GitHub’s secure workflow guidance for permission and secret configuration.

​
Pull requests and forks

When a fork pull request runs on Celesto, the workspace connected to the base repository’s GitHub App installation pays for the job. The base repository is the repository receiving the pull request. Review workflow changes and the requested runner size before approving contributor jobs. Review your repository’s GitHub Actions settings for fork approvals, token permissions, and secret access before routing contributor jobs to Celesto. A fork is a separate copy of a repository; its proposed code should be treated as untrusted until reviewed. GitHub controls approval and credential behavior for workflow events. Check its pull request event documentation against your repository settings. Do not assume Celesto adds a separate approval step or blocks all fork jobs. Keep untrusted code out of privileged pull_request_target and workflow_run jobs. These events can run with access that an ordinary pull request job does not have. A fresh computer limits reuse between jobs; code running inside a job can still use the credentials and network access given to that job.

​
What remains after a job

Cache access uses the workspace, repository, and branch or pull-request permissions granted to the running job. Treat cached files as readable by jobs with the relevant access. Keep secrets in your workflow’s credential controls instead.

​
Ask about your requirements

Contact aniket@celesto.ai before sending data that requires a specific retention period or deletion commitment. Include the workspace, repositories, and the types of records involved. For a suspected credential exposure, revoke or rotate the credential promptly and request removal from every location where it was saved.
Last modified on October 19, 2026