Get startedSign in

Guide on Creating a New Application Artifact

This guide is for anyone who wants to make an open-source application available on the Plural marketplace and create a new Plural artifact.

To add your own application, you'll need the Helm chart for your application and corresponding Terraform.

1. Create a new directory in plural-artifacts

Clone the plural-artifacts repository

git clone

For this getting started guide, let's pretend that we are onboarding Hasura. We have a useful make target to scaffold some of the necessary stubs for integrating with Plural.

plural create

The repository structure after running the make command should look something like this:


In the steps below we will go through and fill out the stubs.

2. Add your Helm chart

This section assumes familiarity with helm, the Kubernetes package manager. If you have not worked with helm before, it's strongly recommended that you read through the helm docs to understand core helm concepts, particularly helm templates and helm template values.

Getting Started with Helm

From the root of your newly created hasura directory, navigate to the helm chart.

cd helm/hasura

A helm chart is organized as a collection of files inside of a directory:

  Chart.yaml          # A YAML file containing information about the chart
  values.yaml         # The default configuration values for this chart
  values.schema.json  # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file
  charts/             # A directory containing any charts upon which this chart depends.
  templates/          # A directory of templates that, when combined with values,
                      # will generate valid Kubernetes manifest files.

The Chart.yaml file contains a description of the chart. You can access it from within a template.

The templates directory is for template files. When Helm evaluates a chart, it will send all of the files in the templates directory through the template rendering engine. It then collects the results of those templates and sends them on to Kubernetes.

The values.yaml file is also important to templates. This file contains the default values for a chart. These values may be overridden by users during helm install or helm upgrade.

You should also see a deps.yaml file. This is a Plural file used to track dependencies and sequence order of installations and upgrades.

Fill out Chart.yaml

Open up the Chart.yaml file.

Chart.yaml is a yaml file containing information about the chart. You can refer to the helm documentation for a comprehensive list of fields in the chart.

The yaml is largely self-documenting. The field to pay attention to is the field at the end, dependencies. If your open source project has an existing helm chart (for example on ArtifactHub), this is where you'll want to link it.

  - name: hasura
    version: 1.1.6

Fill out the templates directory

Next, let's fill out the templates directory. Recall that the templates directory is for template files. When Helm evaluates a chart, it will send all of the files in the templates directory through the template rendering engine. It then collects the results of those templates and sends them on to Kubernetes.

The Plural platform includes a number of custom resources that you might find useful to fully productionize your application and can copy and paste over for your own use:

  • dashboard.yaml -- creates dashboards in the console that reference Prometheus metrics
  • runbook.yaml -- creates interactive tutorials in the console that show how to perform common maintenance tasks. For more documentation on runbooks refer here.
  • proxies.yaml -- wrappers around kubectl port-forward and kubectl proxy which allow you to get shells into running pods, databases or access private web uis
  • configurationOverlay.yaml -- creates form fields to modify helm configuration within the console
  • logfilter.yaml

Fill out deps.yaml

The deps.yaml file is a Plural file that is used for determining the sequence of installations and updates. It should look something like this:

kind: Dependencies
  application: true
  description: Deploys hasura crafted for the target cloud
    - type: helm
      name: bootstrap
      repo: bootstrap
      version: '>= 0.5.1'
    - type: helm
      name: ingress-nginx
      repo: ingress-nginx
      version: '>= 0.1.2'
    - type: helm
      name: postgres
      repo: postgres
      version: '>= 0.1.6'
    - type: terraform
      name: aws
      repo: hasura
      version: '>= 0.1.0'
      optional: true
    - type: terraform
      name: azure
      repo: hasura
      version: '>= 0.1.0'
      optional: true
    - type: terraform
      name: gcp
      repo: hasura
      version: '>= 0.1.0'
      optional: true

3. Add your cloud config

From the root of the hasura/ directory (not the one on helm/ directory but its parent directory), navigate to the terraform/ directory. Terraform is a tool for creating, updating, and destroying cloud infrastructure via configuration rather than a graphical user interface. If you are not familiar with it, we suggest reading through the Terraform docs. The files that are located inside this directory are responsible for creating various cloud objects -- i.e. Kubernetes namespaces, AWS IAM roles, and service accounts.

cd terraform

You should see three folders:


They each have the same structure:

  terraform.tfvars will contain the main set of configuration for your Terraform module. You can also create other configuration files and organize them however it makes sense for your project. It will look something like this:

resource "kubernetes_namespace" "hasura" {
  metadata {
    name = var.namespace
    labels = {
      "" = "plural"
      "" = "hasura"

data "aws_iam_role" "postgres" {
  name = "${var.cluster_name}-postgres"

resource "kubernetes_service_account" "postgres" {
  metadata {
    name      = "postgres-pod"
    namespace = var.namespace

    annotations = {
      "" = data.aws_iam_role.postgres.arn

  depends_on = [
} will contain the variable definitions for your terraform module (the variables are used in

4. Add your Plural config

Finally, let's look at how to set up the config that will go to Plural.

From the root of hasura/, navigate to plural/recipes.


Here, you will specify the other Plural packages that must be installed alongside this package, as well as configuration and documentation for parameters that you will be asking users to input.

name: hasura-aws
description: Installs hasura on an EKS cluster
provider: AWS
dependencies: # Other Plural packages that must be installed alongside this bundle
  - repo: bootstrap
    name: aws-k8s
  - repo: ingress-nginx
    name: ingress-nginx-aws
  - repo: postgres
    name: aws-postgres
  - name: hasura
      - type: TERRAFORM
        name: aws
      - type: HELM
        name: hasura
    configuration: # Users will be asked to input values for these parameters
      - name: hostname
        documentation: Fully Qualified Domain Name to use for your hasura installation, eg if is the domain you inputed for dns_domain above.
        type: DOMAIN

5. Testing Locally

You can validate your changes locally using the plural link command. You'll need to have your packages pushed to plural first, then installed in an installation repo. Once done, you can link your local version of a helm or terraform package using:

plural link helm <app-name> --path ../path/to/helm --name <chart-name>

6. Push your local changes and open a PR

Assuming that you have been working on a branch add-hasura you should now commit your changes and open up a PR on Github against the pluralsh/plural-artifacts repository.

git add .
git commit -m "Integrate hasura changes"
git push