Once a gitlab instance is set up to use kubernetes and auto-deploy, all that is left is setting your environment variables whenever you create a new project. Let’s deploy an app.

We could technically just deploy now, and we’ll be given a review subdomain on our wildcard kubernetes host we set earlier (some-auto-generated-review-environment.k8s.80pxtesting.com). Let’s actually deploy a web page to the domain 80pxtesting.com since we haven’t put anything on the root domain yet. We’ll only deploy to this domain when we’re going to production, and use review URL’s for any merge requests.

Quick question… How does gitlab know how to deploy my application to kubernetes? It’s a good question. There are multiple ways. You will have to learn more about it here to determine which is the best for your project.

Here are a few ways you can auto deploy:

  • Add a .static file to the root of your project to deploy the contents of that folder to a web server
  • Add a Dockerfile that builds and runs your deployment, which also uses and exposes port 5000
  • Use Herokuish to intelligently determine how to build your application

    • For example, if you have a package.json Herokuish will attempt to use Node to run npm run build on the build step, and npm start for the deploy step
  • There are many great example repos of apps that will work with auto deploy as well

gitlab apps

We will do a simple .static file for now. Let’s create a project named after the website we’re going to deploy to. This helps us reference the kubernetes deployment later because they are based on the repository name.

Click the + button on the top of gitlab, and click New project.

Click Create blank project.

Add the name, and make sure it is under the softwarecompany group. Adding the actual URL of the app in the description is nice to have clickable as well.

gitlab new project

Click Create project.

gitlab new project

First, let’s add the DNS record for that domain to point to the cluster’s load balancer IP.

Then, we’ll add environment variables so our project knows which URL to use.

  1. Add @ DNS record to point to the root domain 80pxtesting.com

    at record

  2. Add the auto deploy environment variable to set up the URL for this project.

    When you’re on the project’s main page in Gitlab, go to Settings > CI / CD.

    Expand the Variables section, and add these two variables:



    • Uncheck protected for the TEST_DISABLED job, as we want this to run on all repository branches for now.
    • We are disabling the test job because .static file deployments do not support tests.
    • Remember, we already set a group level variable POSTGRES_DISABLED to disable creating a postgresql pod and spawning a data volume.
    • You can disable any of the jobs that come out of the box with auto-deploy. Technically, as long as the variable exists, the test job will be ignored.


We’re going to edit this repo using the Web IDE button next to the blue Clone button on the main project page.

You can also use git to manage the repository using your SSH but that is a tutorial for another day.

Our end goal will be the same— changing the files in the repo. Gitlab will automatically detect the changes and use Auto Devops like it suggests in the blue banner by detecting one of their many deploy methods.

Open the Web IDE, it should look like this.


Now simply add an empty file (The document icon with the + symbol) called .static

And I’ll also add a barebones HTML page called index.html. We will make an adapted version of index.html on the HTML5 Boilerplate project.


<!doctype html>
<html lang="en">

  <meta charset="utf-8">
  <meta name="description" content="kubernetes served website">
  <meta name="viewport" content="width=device-width, initial-scale=1">


  <!-- Add your site or application content here -->
  <p>Hello from kubernetes.</p>



  • empty .static file
  • basic index.html saying Hello from kubernetes.

Commit the changes and push it to a new branch. Also, start a new merge request. (These are the default options)

This is good practice to test your new auto deploy environment on a review branch, then you can merge it to the main branch and it will deploy to production.


After you hit commit, you will be brought to the new merge request screen. You can add a description and other information to your merge request.


Hit submit merge request to finish.

You will see your application running it’s auto deploy steps. There are a few stages, and each one can have a few jobs.


You can see the app building the docker image and pushing it to the registry (based on on the .static file) in the build stage.

The test stage has a few jobs underneath it:

In a few minutes, this should be done. Your pipeline looks like this.


To find your review environment you can either:

  • Go to the Review job and look at the log to get the URL
  • On the Merge Request the review environment is associated with
  • Go to Environments under Operations on the left

Here is the Environments page after our build and deploy:


Now you can click the Open live environment button.


And we’ll see our website at the automatically generated URL.


Alright! Last thing to do now is push this to production. We like these changes, so let’s hit merge

merge 1

Now we have merged that branch, and a new build will happen for our main branch.

merge prod

If everything was set up correctly, we can now go to the production URL, which we specified in our environment variables.



We did it! We deployed an app to kubernetes using gitlab. We used free software to do this, Big thank you to Gitlab, and all the umbrella software and developers that includes.