Skip to content

OpenFaaS Dashboard

The OpenFaaS Dashboard is a new UI, rebuilt to make operating and understanding OpenFaaS easier.

Note: This feature is included for OpenFaaS Pro customers.

Using the dashboard

Your browser can save the password for your various OpenFaaS environments, so that the credentials can follow you between machines, or be saved in password manager like 1Password.

Login to the dashboard

Login to the dashboard

Once logged in, you'll be met by the namespace selector. Namespaces can be used to group functions together, or to provide a level of isolation between teams using the same OpenFaaS installation.

Select a namespace to explore

Select a namespace to explore

See also: Namespace support

An overview of functions

An overview of functions

Note that the fields such as repository and SHA can be populated at deploy time and integrate into the UI to create links and show you what's deployed.

The details for a function

View the details for a function, including metrics, logs and metadata about its deployment

View logs without a terminal, in one place

The logs of the figlet function, viewed without kubectl or needing separate terminal access.

faas-cli store deploy \
    figlet \
    --gateway \
    --env write_debug=true \
    --env read_debug=true
for i in {0..3}; do curl -d $i ; done

To populate the metadata in the UI, simply set the following at deployment time via faas-cli deploy or the OpenFaaS Custom Resource:

Type Key Example value
label com.openfaas.git-branch master
label com.openfaas.git-owner openfaas
annotation com.openfaas.git-repo-url
label com.openfaas.git-repo store-functions
label com.openfaas.git-sha 665d9597547d8e0425630ba2dbb73c2951a61ce2

Here's an example:

faas-cli store deploy cows \
  --label com.openfaas.scale.min=2 \
  --annotation com.openfaas.git-repo-url= \
  --label com.openfaas.git-owner=openfaas \
  --label com.openfaas.git-repo=store-functions \
  --label com.openfaas.git-branch=master \
  --label com.openfaas.git-sha=f79e2c86e8d67f747d1e449ba6ca63eb5858e5bb

Any of these fields can be replaced through environment substitution in stack.yml or using helm during CI/CD.

Example snippet from stack.yml:

    lang: go
    handler: ./cows
    image: alexellis2/cows:0.1
      com.openfaas.git-sha: ${GIT_SHA:-dev}

Then using environment variables from your CI system such as GitHub Actions or GitLab CI, override any variables you want to change.

Example of injecting the SHA from Gitlab:

GIT_SHA=$CI_COMMIT_SHA faas-cli deploy

Example with GitHub Actions:

GIT_SHA=$GITHUB_SHA faas-cli deploy

When the GIT_SHA variable is omitted, then the text dev will be inputted instead.

See also:


The OpenFaaS Dashboard is installed through the openfaas helm chart, and will also work with faasd.

Before deploying, you'll need to have created a secret for your license, you'll find instruction in the helm chart for this.

Create a signing key

You need to create a JWT signing key and a separate secret for the dashboard. It's used to sign and validate logged in sessions.

# Generate a private key
openssl ecparam -genkey -name prime256v1 -noout -out jwt_key

# Then create a public key from the private key
openssl ec -in jwt_key -pubout -out

# Store both in a secret in the openfaas namespace
kubectl -n openfaas \
  create secret generic dashboard-jwt \
  --from-file=key=./jwt_key \


For easy deployment during development this step can be skipped. The dashboard will automatically create the required signing keys on startup.

Note that these keys will be recreated any time the dashboard container is restarted invalidating any logged in sessions.

Configure the dashboard

To enable the dashboard feature, add the following to your values.yaml file for the openfaas chart:

  enabled: true
  # Name of signing key secret for sessions.
  # Can be left blank for development deployments.
  signingKeySecret: "dashboard-jwt" 

The publicURL, doesn't necessarily have to be publicly exposed on the Internet, but it does need to be a fully qualified domain name (FQDN).

The signingKeySecret can be left blank to auto generate signing keys (See: Create a signing key).

Configure the dashboard with IAM

If you have enabled Identity and Access Management (IAM) for OpenFaaS authentication to the dashboard happens via OpenID Connect(OIDC). This requires a few extra configuration steps.

  1. Configure an OIDC provider.

    If you have already configured your OIDC provider and registered it with OpenFaaS this step can be skipped. If you did not configure any providers or want to register a separate provider for the dashboard continue.

    You must configure your provider and create a new client app for OpenFaaS. For precise information see the documentation of your OIDC provider.

    The dashboard has support for the following authentication flows:

    • Authorization Code Flow
    • Authorization Code Flow with Proof Key fo Code Exchange (PKCE)

    Once your provider is configured it needs to be registered as a JWT Issuer with OpenFaaS. See: register a provider

  2. Generate AES encryption key

    An AES encryption key needs to be generated and stored in secret in the openfaas namespace. This AES key is used to encrypt the OpenFaaS access token.

    # Generate a key
    openssl rand -hex 16 > aes-key
    # Store the key in a secret in the openfaas namespace
    kubectl -n openfaas \
      create secret generic aes-key \
  3. Create a Kubernetes secret for the OAuth client secret

    This step can be skipped if the issuer used for the dashboard does not need a client secret. Retrieve the client secret from your identity provider and store it a file client_secret.

    kubectl create secret generic \
      -n openfaas \
      oauth-client-secret \
      --from-file client_secret=./client_secret
  4. Configure the OpenFaaS deployment

    Add the following to iam section in your values.yaml file for the openfaas chart:

        # URL if the issuer
        url: ""
        clientId: ""
        # Name of Kubernetes secret containing the client secret.
        # Can be left blank if a client secret is not required e.g for the PKCE flow.
        clientSecret: "oauth-client-secret"
          - openid
          - profile
          - email

    The clientSecret can be left blank if your OIDC provider does not require a secret.

    Depending on your provider and setup you might need to request additional scopes. These can be set through the scopes parameter.

Access your dashboard via port-forwarding

If you don't want to expose your dashboard to users over the Internet, then you can access it as and when required using port-forwarding. Instead of giving a domain and DNS record, you can set the public url in your values.yaml file to localhost or an empty string.

  enabled: true
  publicURL: "localhost"

To access the dashboard run the following, whenever you need it:

kubectl port-forward \
  -n openfaas \
  svc/dashboard 8081:8080

The username is admin and the password is the same one used for faas-cli login.

Then access the URL via

Expose your dashboard on the Internet

Once deployed, you can leave your dashboard private, and access it via port-forwarding, or create a Public Ingress record to access it over the Internet.

There two three options for Public Ingress:

  • Kubernetes Ingress Controller
  • Istio Gateway/VirtualService.

If your cluster does not have a public IP, but you still want to access the dashboard over the Internet, we have included notes on how can help.

Assuming you already have a Let's Encrypt Issuer and are using ingress-nginx, you could use the following example:

export DOMAIN=""
export INGRESS_CLASS=nginx

cat > ingress.yaml <<EOF
kind: Ingress
  name: openfaas-dashboard
  namespace: openfaas
    app: openfaas-dashboard
  annotations: letsencrypt-prod "true"
    $ "true" $INGRESS_CLASS
  - host: $DOMAIN
      - backend:
            name: dashboard
              number: 8080
        path: /
        pathType: Prefix
  - hosts:
    - $DOMAIN
    secretName: dashboard-cert

TLS is mandatory, and you'll use your OpenFaaS password to log in with your browser.

A much simpler alternative for local testing and development is to set up an inlets VM in HTTPS mode: inlets automated HTTP server.

apiVersion: apps/v1
kind: Deployment
  name: inlets-dashboard-client
  namespace: openfaas
  replicas: 1
      app: inlets-dashboard-client
        app: inlets-dashboard-client
      - name: inlets-dashboard-client
        imagePullPolicy: IfNotPresent
        command: ["inlets-pro"]
        - "http"
        - "client"
        - "--url=wss://EXIT_SERVER_IP"
        - "--token="
        - "--license="
        - ""
        - ""

You can use the same tunnel and exit server for multiple domains, to expose both the gateway and the dashboard with TLS and authentication.

Would you like a demo?

Feel free to reach out to us for a demo or to ask any questions you may have.