GitHub Actions Starter Workflows: Ready-Made CI/CD Templates Served Through the GitHub UI

What Starter Workflows Do and When GitHub Shows Them

When a user navigates to the Actions tab of any GitHub repository and clicks to create a new workflow, GitHub presents a catalog of template workflows to choose from. The files in actions/starter-workflows are the source of that catalog. Each template is a working YAML file that defines a complete workflow, appropriate for a particular language or deployment target. GitHub selects which templates to display more prominently based on the language and technology stack it detects in the repository.

The repository does not contain a standalone application and does not need to be installed or cloned to use the templates. The primary access path is through the GitHub Actions UI directly. The README says to click the Actions tab in the repository where you want to create a workflow, and the templates will appear there automatically.

The README also notes that the project is not currently accepting contributions. The maintainers have stated they are directing resources toward other areas of GitHub Actions and will provide security updates and fixes for major breaking changes, but will not review or merge new workflow templates from external contributors.

Repository Layout: Five Purpose-Based Directories

The repository organizes templates into six directories. The ci/ directory holds continuous integration workflows for building and testing projects in various languages. The deployments/ directory holds workflows that push artifacts or code to hosting environments. The automation/ directory contains workflows for automating repository tasks such as issue management or pull request labeling. The code-scanning/ directory holds workflows that run static analysis tools. The pages/ directory holds workflows for building and publishing GitHub Pages sites. The icons/ directory holds SVG icons used in the GitHub UI alongside each template.

This layout reflects the five categories of automation that GitHub Actions supports in the onboarding UI. A template in ci/ for a Django project coexists with one for Gradle and one for Rust, all in the same directory, distinguished only by filename and their .properties.json metadata.

Each template is a pair of files. The workflow file has a .yml extension and must be valid YAML. The companion .properties.json file contains the metadata that controls how the template appears in the GitHub UI. Both files live in the same directory, with the properties file in a properties/ subdirectory. For example, a CI template for Django would be ci/django.yml and ci/properties/django.properties.json.

Using a Starter Template to Create a New Workflow

To use a starter workflow in a GitHub repository, navigate to that repository's Actions tab, click New workflow, and select one of the displayed templates. GitHub copies the template's YAML into a new file in the .github/workflows/ directory of the repository. From that point, the workflow is a regular Actions workflow file that the repository owner controls and modifies.

The template variables in the YAML are substituted by GitHub at copy time. The $default-branch variable becomes the repository's default branch name, whether that is main, master, or something else. The $protected-branches variable expands to any branches that are protected in the repository settings. The $cron-daily variable substitutes a valid but randomly assigned time within the day, which distributes cron-triggered runs across GitHub's infrastructure.

To preview a template before it becomes publicly visible in the catalog, template authors add a labels array containing preview to the .properties.json file:

{
    "name": "Node.js",
    "description": "Build and test a Node.js project with npm.",
    "iconName": "nodejs",
    "categories": ["Continuous integration", "JavaScript", "npm", "React", "Angular", "Vue"],
    "labels": ["preview"]
}

With that label present, the template only appears in the UI when the user appends ?preview=true to the new workflow page URL. Removing the labels array makes the template visible to all users.

Properties File Metadata and How GitHub Uses It

Each template's .properties.json file controls its appearance in the GitHub onboarding UI. The name field is the title shown to the user, and it must be unique across the repository. The description field provides a short explanation. The iconName field links to an SVG in the icons/ directory, or it can reference an octicon from the Primer icon library by prefixing the icon name with octicon followed by the name.

The creator field is an author attribution shown in the UI. All templates from the same author share the same creator value. The categories array controls which sections of the catalog the template appears under. At least one category from the defined list is required: the list includes continuous-integration, deployment, testing, code-quality, code-review, dependency-management, monitoring, Automation, utilities, Pages, and Hugo. Additional categories can be added from the list of languages in the GitHub Linguist repository and the list of tech stacks in the repo-analysis-partner repository, both linked from the README.

When a user's repository is detected as containing a particular language or tech stack, GitHub promotes templates whose categories match that detection. This is why the categories field is worth setting precisely: a template that lists JavaScript and npm in its categories will appear more prominently for JavaScript repositories than one that lists only continuous-integration.

What Starter Workflows Do Not Cover and What to Do Instead

Starter workflows are starting points, not finished pipelines. Each template defines the minimum viable workflow for a given stack, typically a build step and a test step on a standard runner. Caching dependencies, matrix testing across multiple runtime versions, uploading artifacts, deploying to cloud environments, or notifying external services all require additions to the generated workflow file.

Writing a workflow file from scratch using the GitHub Actions documentation covers the same ground as a starter template. The difference is that a starter template has already been validated to work for the named stack, while a from-scratch file requires the author to discover the correct action names and input parameters independently. For unusual stacks or custom infrastructure, writing from scratch is often faster than adapting a template, because the template's assumptions about the build environment may not match.

The template variables $default-branch, $protected-branches, and $cron-daily only apply at copy time. Once a template has been copied into a repository's .github/workflows/ directory, those variables no longer exist. Any further changes to branch names or protection rules in the repository do not automatically update the workflow file.

Maintenance State and Absence of Contribution Path

The repository is not archived. The last push was on 2026-08-03. The README includes an explicit notice that the maintainers are not accepting contributions at this time. External contributors who report bugs can use the Community Discussions area or GitHub's support contact for high-priority bugs, and security issues are handled through the security.md policy. Raising bugs in the repository directly is still permitted.

This maintenance stance has a practical consequence for organizations with niche stack templates that are missing from the catalog. There is no supported way to add them through this repository. Organizations can maintain their own workflow template repositories and configure GitHub Enterprise or internal tooling to serve templates from those repositories instead.

The license for the repository is listed as NOASSERTION in the repository metadata, meaning the license type could not be detected automatically. The README does not include a license section. Users who need a confirmed license for compliance purposes should consult the LICENSE file at the root of the repository.

Editorial conclusion

Teams building CI/CD for common stacks such as Node.js, Python, Java, or Docker will find the starter templates a useful starting point that already handles basic patterns. Teams with custom deployment targets or internal tooling should expect significant modification before a template is useful, since the templates are written for common public stacks only. The repository currently does not accept contributions, so organizations that need templates for unusual environments have no supported path to submit them. The preview label mechanism in properties.json is the only documented way to test a template against the GitHub UI before making it visible to all users of a repository.

Frequently asked questions

Official sources

1. actions/starter-workflows on GitHub
2. Issues
3. Project website
4. README