BuildPiper – A SAAS Playground

Buildpiper - A SAAS Playground

As of late, I took a dive at setting up and connecting WordPress with the database using container services. I created a website but couldn’t figure out where and how to deploy it. I was looking for a way with less exertion, at least expense, and minimum time. At this point, I thought of a SAAS product by Opstree Solutions called BuildPiper. I’d been wanting to try it for some time now and this looked like a good opportunity. Going in, I thought I’d have to go through the usual chores of using a new product, tons of documentation, hit and trial, etc. before I could get the hang of it. I wasn’t expecting a functioning website until at least the end of the day. But as soon as I had signed up, the onboarding felt like a smooth stream. I was able to deploy my site in less than an hour.


BuildPiper gives the adaptability to set up applications with or without the manifest. On the off chance that somebody would not like to use the manifest, BuildPiper, additionally, gives a choice to create it using GUI, which is as basic as topping off a structure. BuildPiper is a powerful container management platform that automates and comprehensively simplifies the application delivery process. It is a unified container application delivery platform, that enables the dockerized code to be deployed to production immediately with all the required observability, security, and compliance baked in.

My experience with BuildPiper SAAS playground!

For me, I used WordPress as my container service which connects with MySQL containers in my setup.

Architecture diagram

For this application, I am using two Dockerfiles which are used to configure two different pods:

  1. WordPress application
  2. MySQL Database

MySQL database is a private service and need not be exposed publicly. Using BuildPiper, we can restrict and expose any pod/service inside our cluster. Therefore, I decided to create a private pod structure for the database and went on ahead to create and expose the WordPress pod structure publicly using the BuildPiper ingress feature.

BuildPiper gives the flexibility to use environment variables like setting up build & deploy environment variables. MySQL database contains some deploy environment variables like MySQL username, default root password, etc. 

For WordPress containers, I am using a few build environments like WordPress username, password, database name, and database URL which I injected through BuildPiper.

Required Steps to configure/setup in Buildpiper Saas

First, we have to provide the service details for container service like

  1. service-name
  2. language supported by container service
  3. repository URL
  4. credentials detail
  5. build type 
Service information for application


Now, we have to provide an environment type for microservice as BuildPiper supports multiple environments.

Environment type for Application


For the first part, we have to provide basic information about cluster and repository like 

  1. the cluster, which is provided by BuildPiper in the playground
  2. the namespace associated with the linked account
  3. repository branch
  4. Dockerfile path for container application which is common for both services [ WordPress & Database ] in my case
Basic information about Application


The second part contains information about build variables and CI [ continuous integration ] information for service.

For my application, I provided build variables which are used by WordPress:

  1. Database
  2. Database username
  3. Database password
  4. Hostname [ Get from database service URL value ]
Build variables for Application


After setting up WordPress Build variables & cluster information for both WordPress and database setups, we have to provide resource Quota like CPU, RAM & replicas for different applications.

Resource quota for Application


Now that we are done with that, we can provide access level information for our container application.

In this case, we need public access to WordPress containers through ingress routing. For this, we have to provide some information like: 

  1. URL Name [ ]
  2. Expose Path
  3. Service Port
Access level information for Application


For database pods, we need private access from our application. For this, we will choose private as ‘Access Level’ and provide the name/URL for the database along with the port which is used as build variables for the WordPress application.

Access level information for database


Next is an advance level configuration which is based on Scalability [ auto-scaling ], runtime/deploy environment variables, vaults, liveness probe, and readiness probe.

Advance level configuration options pop-up


We can either skip it or continue with the configuration to take advantage of advanced configuration options,

For our case, we only needed runtime/deploy variables for our database

Deploy/runtime Environment variables for MySQL


Note: This is one time setup for each service & deployment and doesn’t take much time. Each service has its own interface where we can update/modify it.

After setting up both database & WordPress application services using BuildPiper, we can click on a service overview to view all services configured.

Service Overview


Finally, we have to Build & deploy to make sure everything is working fine. 

We will first Build & deploy our database application as our WordPress application depends on the database.

To build database [ same for WordPress application ],

Service dashboard for database 


On pressing build, it will ask for the tag name [ optional ] and branch [ optional & default branch that we already set-up while configuring service].

Build options for database service


The build will create a docker image from Dockerfile that is present in the repository path,

Once the build is complete, we can deploy the database pod from the built image. For this, we can click on the deploy icon and select tag as required. 

Deploy database service in Buildpiper k8s cluster


We can setup the WordPress application using the same set of steps.

Now that we are all done, we can use our public ingress URL [ ] which we provided during setup to access the website.

URL – http:/

WordPress site hosted on Buildpiper SaaS


In the service dashboard, we can also check multiple things like 

  1. Build & deploy status
  2. Latest Artifact name while building
  3. Current deployment artifact
  4. Commit ID & messages
  5. Build & deploy date
  6. Build by & deploy by 

Cool, right? I wasn’t kidding when I said, “comprehensively simplifies the application delivery process.”

Service dashboard overview 


Benefits of BuildPiper Saas

  1. BuildPiper gives multiple ways to configure application deployment:
    Build manifest with UI
    Upload manifest file
  2. CI/CD pipeline for single/multiple deployments
  3. Multiple language CI support
  4. Single click Build/Deploy
  5. Buildpiper also maintains build & deploy log history for each artifact
  6. Onboard a Dockerized service in minutes
  7. Setup & Run hassle-free secured Pipelines
  8. Enable the most robust & secure DevSecOps CI in a few clicks
  9. Single click service modification
  10. Easy interface to visualize the configuration
Thats Gonna Be Really Useful Very Useful GIF - ThatsGonnaBeReallyUseful VeryUseful Helpful GIFs


Know more about BuildPiper Saas & features

To set up the first containerized application on BuildPiper Saas, visit:

Gif Source

Opstree is an End to End DevOps solution provider


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: