Skip to content

Deploy your Application#

There are multiple ways to deploy your Application on the Cluster.

  • For development with tilt follow the below tutorial. Use tilt for deploying the application on test clusters.

    This is the recommended local development workflow

  • For Deployment via GitOps, follow this guide for Deploying the Application with GitOps

    This is the recommended production workflow


  • Learn local development for testing and developing applications on local/lab clusters.

Key Results#

  • Deploy the application with tilt.
  • Deploy the dependency of the application.


In this guide, we will deploy an application with tilt and namespace in the remote OpenShift cluster

  1. Clone this sample repo Nordmart-review

  2. You should have a namespace in remote/local cluster; If you are in SAAP then enable sandbox namespace/project/environment for your tenant; you can read more here

  3. Log in to the cluster via OpenShift CLI, and copy the login command from your username tab as discussed in the previous tutorial.

  4. Switch project to sandbox namespace/project/environment

    oc project <MY-SANDBOX>
  5. Log in to OpenShift internal docker registry

    First, get the OpenShift internal docker registry URL and set in the HOST variable name


    NOTE: Ask Customer Admin or Cluster Admin to provide you with the OpenShift internal registry route

    Then login into the docker registry with the following command:

    docker login -u $(oc whoami) -p $(oc whoami -t) $HOST

    If you get this error x509: certificate signed by unknown authority then you need to update your /etc/docker/daemon.json file and add the insecure registry

        "insecure-registries" : [ "HOST" ]
  6. (Optional) Add Helm chart repos

    If you reference Helm charts from the private registry then you first need to add it

    cd deploy
    # Helm credentials can be found in Vault or in secret in the build namespace
    helm repo add stakater-nexus <private repo URL> --username helm-user-name --password ********
    cd ..
  7. Update Helm dependencies.

    cd deploy
    helm dependency update
    cd ..
  8. Go through the Tiltfile of the application

  9. Check the local_resource section in the Tiltfile

  10. Create tilt_options.json file

    Remove .template from the file named tilt_options.json.template

    Create tilt options JSON

    And then fill up all three things

    1. namespace: your sandbox environment name
    2. default_registry: the OpenShift internal registry route (you have set in step # 6 in HOST above) and then add your namespace name after /
    3. allow_k8s_contexts: given you are logged in the cluster; then run oc config current-context to get the value for allow_k8s_contexts


          "namespace": "tilt-username-sandbox",
          "default_registry": "image-registry-openshift-image-registry.apps.[CLUSTER-NAME].[CLUSTER-ID]",
          "allow_k8s_contexts": "tilt-username-sandbox/api-[CLUSTER-NAME]-[CLUSTER-ID]-kubeapp-cloud:6443/"
  11. Go through the .gitigore and check tilt and Helm specific ignores

    # ignore tilt files
    # ignores helm files
  12. Go through .tiltignore.

  13. Go through values-local.yaml in a tilt folder in the base application directory.

    values-local.yaml should contain the following content. Make sure that the replica count should always be 1.

        imagePullSecrets: null
        # Tilt live update only supports one replica
        replicas: 1
          tag: null

    In our application setup, we have a dependency on MongoDB for storing and managing data. As part of our deployment process, we will ensure that both the application API named review and MongoDB named review-mongodb are deployed together to confirm proper functioning. This dependency ensures that the application can seamlessly interact with the database and access the necessary data. To understand more about application architecture, visit here.

  14. To add mongodb dependency, add this YAML to your deploy/values.yaml file.

      fullnameOverride: review-mongodb  # Name for the MongoDB deployment
      updateStrategy:  # Specify the update strategy for MongoDB pods
        type: Recreate
      resources:  # Define resource limits and requests for MongoDB
          memory: 1Gi
          cpu: 0.5
          memory: 128Mi
          cpu: 0.1
      auth:  # Enable authentication for MongoDB
        enabled: true
        existingSecret: review-mongodb-creds  # Reference an external secret for MongoDB credentials (created via Vault)
      podSecurityContext:  # Disable or enable if you require pod-level security context settings for MongoDB
        enabled: false
      containerSecurityContext:  # Disable or enable if you require container-level security context settings for MongoDB
        enabled: false

    It should look like this:

    MongoDB values


    The indentation should be followed as mongodb. So you can define MongoDB values as a separate entity, because we are going to deploy a separate pod named, review-mongodb.

  15. Validate that the review application is not running already

    sandbox namespace

  16. Save the values.yaml file and run tilt up at the base directory of your repository.

    tilt up

    Open the tilt browser; just hit the space

    tilt browser

    If everything is green then the application will be deployed in the cluster. By this we mean two pods will and 2 deployments will be created.

    sandbox namespace

    Let's view your application pods

    pods error

    We can see there is an error on both API and MongoDB pods. Let's see the events of both pods to find the actual error:

    review pod error MongoDB pod error

    There is a secret missing named, review-mongodb-creds.

Let's create this secret in the next chapter and deploy the app.