Proxmox IaC With GitLab + Terraform | Part 1: Automated VM Builds

Added: 2026-05-31

[00:00:00]Hey, welcome back to the channel. Now, we're back in our DevOps series, and I've been thinking a lot as to how I want to approach this series, and I'm thinking I'm going to switch things up a little bit with this build. In the last video, I had planned to walk through a test pipeline build, but I want to skip that and jump straight into building one of the main pipeline in this environment. And I'm doing that because I have a lot a lot to cover in this environment. and I rather just bring you guys along as I go rather than pause and then create a separate video every time I'm talking about something new. So let's talk about the first hurdle that I need to clear in this environment. Now up until this point I have been manually creating VMs and container in Proxmox every single time I want to set up a new server or a new container and given the fact that the whole point of this whole build is to automate everything that needs to change. Now, before I can do anything else in this environment, I need to get my infrastructure as a code strategy in place. And now that the repo is fully up and running, it's time to do exactly that. So, the first goal here is to build a pipeline that automate VM deployments inside of Proxmox. Now, there's a lot more to set up down the road, but like I've been doing, I want to take things one piece at a time. So, this video is going to focus on structure and automating server builds.

[00:01:19]Let's go ahead. Let's get started.

[00:01:24]Okay. So, the first thing I'm going to do is I'm going to start in GitLab. If you're not familiar with what GitLab is or what a repo is, make sure you go check out the previous video. You will need that context to be able to continue with this video. The first thing I did is to set up my groups and my project in GitLab to keep everything organized. And here's a structure that I decided to go with. So you have the main group which is the dev lab group that's going to encompass all of the everything in the environment and then I have the subgroup which is the infrastructure group. This is where a lot of the infrastructure stuff are going to live and then of course I have a project which is the project in GitLab is the repo which is going to be Proxmox which is Proxmox infrastructure as a code. This is where all of the infrastructure as a code stuff for Proxmox is going to live. Now the idea here is to keep things clean and scalable as the environment grows. Now more repos are going to leave under infrastructure but for now I'm going to focus mainly on Proxmox infrastructure as a code repo because the idea is to kind of get it to the point where I'm able to deploy and manage everything using the Proxmox IA repository. The process for creating a new group is pretty straightforward. You go to the group tab. You click on new group. You click on create group and then you give the group a name and then you set the visibility level of the group and then you can set other options as well and then you hit create. The process for creating a subgroup is pretty much the same. You'll go into the group that you want to create the subgroup in and then you click on create subgroup. Now one thing to keep in mind is that it will be nested under the main group. So it will kind of inherit some of the features of the main group. Now you can also import group groups if you choose to. If you have a group from somewhere else and you just want to import it, you can do that.

[00:03:09]I don't have that, so I just created a new group from scratch. Creating a project is a very similar workflow. I just click on create project inside of the infrastructure group because I do want the project. Remember projects are the main repo that we're going to be interact with. And I want that to exist inside of the infrastructure subgroup.

[00:03:25]So I just click on create inside of the infrastructure subgroup. Um, and I started with a blank project, right?

[00:03:30]Since I don't have any template or any other project to import and of course I name the project proxmox IA and I check all three of the boxes that you see here which one is for the readme file creation the other one is for secret detection and then the other one is for secret vulnerability scanning. Once you're done with everything that you want to set you just go ahead and click on create repo and this will automatically create the report that would leave inside of our infrastructure subfolder. This is the first thing I had to do to set up that structure inside of GitLab. Remember, GitLab is kind of my central repo. This is where all of my code configuration is going to live. So, I need it to be very well structured and starting with infrastructure and starting with like the dev infrastructure and Proxmox IC gives me that structure that I need inside of GitLab and that is very important once you start scaling. You need structure.

[00:04:21]Now before I start showing you guys the different components inside of the Proxmox IA repo, I want to chat about few tools I needed to understand to make this whole thing work. Now this tools are very important. These are the tools that are going to come together to be able to allow us to deploy things to Proxmox from GitLab. So it's very important for us to understand this tools and how it all connects together before we even start working on the repo and working on other things. First on the list is GitLab. Now, this is the tool that we're just in and I've also created a dedicated video about it. So, go watch the previous video in the DevOps series if you haven't seen it yet. This is the platform that just basically store our code or my code in this environment and run the pipelines that I'm going to build in this environment. Now, another tool that we need to understand as well are GitLab runners. Now this is another gitlab service that lives on the Proxmark server and is responsible for actually executing the job we define in our GitLab pipeline. So basically just think of GitLab as the brain of like the whole thing and then think of the runners as the hands that do all the work. The next tools that we need to understand are Terraform and Open Tofu. These two tools are essentially pretty much the same thing. Open Tofu is actually an open-source fork of Terraform. So either one will work just fine here. Now what these tools do is that they take the infrastructure as a code that we write in our pipeline and then they turn it into actual VMs inside of Proxmox. So basically you write the specs, they build the VM. And of course I need Proxmox, right? Because Proxmox is what is basically going to house all of my compute. But there are few specific things I needed to set up inside of Proxmox to make sure that GitLab is able to facilitate the communication with Proxmox so Proxmos can build the things that we wanted to build. The first thing that I needed to set up inside of Proxmox is the cloud init template. Now this is kind of like a reusable VM image that automatically configure itself on first boot using cloud in it. It handles things like user account, SSH key, networking, and startup script. Now, this is the image that Terraform or Open TOEFL will clone every time I need to spin up a new VM. The second thing that we need is Proxmox API token. This is basically what allows Terraform or Open Tofu running inside of our pipeline to actually communicate with Proxmox and tell it exactly what we want it to do.

[00:06:56]And the last thing that we need is docker. The pipeline is going to use docker to pull down the terraform or open to container and run it on the runner that is running on the proxmox server. Now the good news is our pipeline handled the docker installation automatically. So that's one less thing we have to worry about inside of proxmox. But we still need to be aware of. So now that we know the tools that we're going to use, let's walk through how everything connects and flow together because that is very important.

[00:07:27]I feel like that is what is not talked about a lot sometimes because a lot of times when you talk about like DevOps tools or automation tools, they kind of talked about in silo, but the reality is that all of those tools kind of work together to make sure that you are able to automatically deploy the things that you want to deploy. All right, so pretty much everything starts inside of GitLab.

[00:07:48]Now I have my Proxmox repo that we just set up. And inside of that, which we haven't looked at yet, we're going to have a Terraform code or if you like Open Tofu, you have a Open Top code inside of that. And when I'm ready to build, I will kick off the pipeline. Now the pipeline can be kicked off inside of GitLab or it can be kicked off by kind of committing a change from your local computer that gets pushed up to GitLab.

[00:08:14]Next step in the process is that our pipeline reaches out to the GitLab runners which is the service sitting on my Proxmoke server and it hands off the job to it. The runners then spin up a docker container and pulls down the Terraform image inside of it. This is basically how I am going to avoid having to manually install Terraform anywhere at all. Once Terraform is up and running inside the container, it basically uses the API token to authenticate with Proxmox. This is the API token that we are going to create. That token will be stored securely as a CI/CD variable in GitLab. So, it never leaves inside of our code. Now, one of the things that we're going to do later on in this series is we're going to set up a secret manager to be able to kind of help manage those things as well. From there, Terraform talks to Proxmox. It grabs my cloud init template and then it provision a brand new VM based on whatever specs I define in my code inside of GitLab. So, this includes CPU, RAM, storage, network, all of it. Once the build is done, the pipeline cleans up after itself, destroying the Terraform container. The runner then goes back to a clean state ready for the next job. And that right there, that is the beauty of automating things or of this whole setup. The next time I need a new VM, I just update my Terraform code, run the pipeline, and the whole process repeats itself automatically. No manual clicking around in Proxmox required at all. All right. So, now that we have like a good understanding of the process itself, let's go ahead and let's start setting things up. So the first thing I needed to do is that I needed to download the cloud image that our template will be built from. For this build, I'm using YUbuntu. So I head over to the YUbuntu cloud image page. From there, I selected the noble folder and then I selected the current folder. The image that I grabbed in the image that you need to make sure you grab is the image that's labeled um cloud image- AMD64.g.

[00:10:13]And also you need to make sure the label has QC cal 2 UFI and GPT on it. So you can do Ctrl find or Ctrl F to be able to just type this in and be able to find it. Once you find it, you want to right click on the image and then click on copy link. After I grab the link of the image that I want to use, I head back to my Proxmark server. Now keep in mind that this is your actual Proxmox server.

[00:10:35]So this is your Proxmox host. You want to navigate over to the shell of your Proxmox host and then you want to navigate to your ISO folder. This is where your images are saved locally. You can cd into this folder. Once you cd into this folder, you'll be able to see all of the images on your host or all of the images that you have uploaded to your Proxmog server. What we want to do at this point now is we want to use wgets to pull down the image using the link that we copied. And what we want to do now is we want to run this command.

[00:11:10]What this command is basically doing is that it's grabbing the image that we just copied or the image that we just looked at on the YUbuntu um website.

[00:11:19]It's going to pull that image down into the ISO folder on our Proxmox host. Now you may need to give it some time depending on your environment or how fast things are in whatever environment that you're running this on. But now that we have the image, we need to create an emptyVM shell that we can attach this image to. And then we're going to convert this image into a template that we can use in our pipeline. Creating the VM that we're going to use for the template is pretty straightforward. You just click on create VM and you can name this VM whatever you want. In my case, I'm going to call it YUbuntu cloud uh and then let's do temp because I already have one called YUbuntu cloud template. So you can call this whatever you want. So you can call it like YUbuntu cloud template. Um in my case, I'm using temp because I already have one that is called template. So and for this guy, what we want to do is we want to the VM ID. First of all, we want to copy the VM ID because it's something that we're going to need uh later on.

[00:12:18]But we also want to have a VM ID that's a little bit further off from the rest of our VMs. Now again, that's absolutely up to you. You can do whatever it is that you want, but in my case, I just like my um templates to be a little bit further off for my VMs because it just allows me it allows me to be able to kind of just go off of that. So since I already have 1,00 I think. So I'm going to do 1,001, right? Um so that's a little bit further off. So the next one can be 10, 102, 1,0003 or 1,100 or 2,000, whatever it is that you want. So we're going to leave the name um the node here. The node here is of course um Odin. And then here I'm going to say DevCI and I'm going to click next. All right. Um for CD, you don't need any of that. Again, remember just keep in mind that this is a template. So we're going to say do not use. Um Linux is fine. And then for system um we're going to say default here. And then we're going to see Q35 here. And then for BIOS, we're going to use UFI. Uh we don't need this disk. So we're going to uncheck that. And then for QM agent, we can leave that uncheck.

[00:13:23]Um TPM, we can also leave that uncheck.

[00:13:25]Just remember that this is a template, right? Eventually, um ideally what we want to do is create this template and then once we start setting things up in our pipeline, our pipeline can make all of these changes for us. So we don't have to do this thing manually. So it's bare minimum so to speak. So for disk, we do not need any disk. So we can go ahead and delete that. Um for CPU because again we're going to attach that disc to this VM. Um so we don't need any disk. Uh and then for CPU we you can do two. Um two is cores is fine. We can do three if you want. Again this is only irrelevant. I hate to sound like a broken record but all of this is irrelevant because again ideally this is just a template. For memory we're just going to do five um 048 for now. Or maybe just to round it up, just do five um gigs for now. And then for networking, um you can either say no networking, but for now, I'm going to say uh let's put that on the DevC. And then you can leave the rest of this default. So again, very simple VM, right? Very straightforward. And then we're just going to do finish and confirm. What's going to happen is that that VM is going to be created. As you can see, I already have one that I'm already using here, which is uh 10,0001.

[00:14:35]And this one is called YUbuntu cloud template. And then this one that I just created is called YUbuntu cloud temp.

[00:14:41]Another thing that you want to be aware of as well is the storage. You want to make note of your storage because you're going to need to know the name of your storage that you're going to use to import the image that we just downloaded. So when we're going to go through the conversion process to kind of convert that image and attach that image to our 10VM that we just created, we need to also tell um Proxmox where or what storage to save that image in. So just be mindful of what storage you want to use and then make note of the name of that storage. You don't have to overthink the hardware settings here.

[00:15:16]This VM is just a shell and the specs don't really matter because the specs is going to be defined by your code or by your pipeline. So you don't have to worry too much by giving it the best of the best here. It's just a shell that is going to be converted into a template.

[00:15:32]Once the VM has been created, what we need to do next is we need to run this command to input the cloud image into a Proxmox storage that we specify and it's also going to convert it into a format compatible with the storage back end.

[00:15:46]One thing to keep in mind is that wherever you're running this command, you need to make sure this image is located in that folder or you're going to need to point this command to that folder where the image is located. In our case, when we pull down the image, we pulled it down in the ISO folder. So, we're basically running it in the ISO folder. So, the command will be able to see this image. So, real quick, uh the import QM import this command, it's running on this guy, which is our VM, which is one. Remember I told you to uh keep track of the VM ID. So this is basically the VM ID. We're pointing it to the image um that we want to import or convert and then we're telling it what storage we want to use to store this image even though we're attaching it to this VM. So that's one of the reason why I said or that's the main reason why I said you need to remember your storage name and you need to remember your VM um ID as well. The reason why I had to do it this way is because the QM import disk is required since cloud images are standalone disk file that must be imported into Proxmox managed storage before they can be attached to and used by a VM. And during the import process, the image is also converted if necessary so it can be used with the VM. So with the disck fully imported, again this might be a little bit slow or a little bit fast depending on your environment. The next thing that we need to do is we now need to go back to our template and we're going to make some changes. And here's what I had to do to kind of complete the setup. So now we have imported the image to our VM. So now what we want to do is we want to navigate to that VM. So we're going to go to our VM here which is 101. And then once we're in that VM, I'm going to minimize this thing so we don't get distracted. Once we're in that VM, if we go to hardware here, we can see that there's already an unused disc here. So this is our um YUbuntu cloudinit image that we just mounted on this VM. That's where it's located. But as you can see that it's not completely mounted yet on our VM. So even if we want to do anything right now or to start this VM, it's not going to work because nothing is mounted on this VM. So what we want to do is we want to attach this disc to our VM. And to do that, it's pretty straightforward. We just double click on the disc. We select the device right here. And then we say, hey, we want discard. if you want to check that. If you don't, you can leave that. Um, and then ISO thread if you want to check that as well. Or if you don't, you can leave that cache. You can make changes here if you want. Again, I'm just going to leave those as default. Um, yeah, because I don't necessarily need those right now. And then, of course, this is the disc that we selected and all we have to do is pretty much just click add. So, once we click add, we can see now this disc has been added here and it's good and ready for us to use. But a few more changes that we are going to need to make. Number one is if we come to cloud init now we can see that the cloud init drive has not been added. So what we want to do now is we want to add the cloud init drive to this VM. So we're able to set things like username, password, DNS, DNS server and SSH key.

[00:18:42]So every time the the server boots up, it just grab this information from the cloud initate drive and then just use that to be applied on the VM that we're booting up. Right? So whatever configuration that we're setting up. So to do that, what we want to do is we want to go back to hardware. We want to click on add. And then we want to go down here and then click on cloud init drive. And then it's going to ask us, hey, where do you want to save the storage? We want to save it in a sim location where the VM and all other data are located. Uh in my case is SSD OCI, right? Um and then you can change things here, right? The device type, you can change that there. And then you just click on add. Once that's added, if we now go back to cloud init, you can see that we have now our cloud init section enabled and not grayed out. And here we can set the username. So the username is going to be ko r m a t chromitech. And then we can set the password um whatever we want here. I'm just going to double click on that. And we can set a password. All right. And then we click okay. And then for DNS name, if you already have that, you can set that. Uh DNS server, you can set that. SSH key.

[00:19:50]You can also set that um upgrade package this stuff. What that basically means is that every time the VM boots up, it's going to automatically run through the upgrade and then upgrade the server for any packages that need to be upgraded.

[00:20:01]So, it's always good to leave this as yes. And then IP config for here. You can either set this to static. So, this mostly depends on how you're going to configure things on your pipeline. And again, we're going to talk about that in detail. Um if you're going to set up your pipeline so that when VMs are created automatically an IP address a static IP address is assigned to them then you don't need to do anything here.

[00:20:22]You can leave that as static and then once the pipeline go through and build things then it will just apply that static IP address to the server itself or you can say something like DHCP um so that the server can look for an IP address as soon as it hits a particular network. Uh for now I'm going to leave it as DCPA. And this is something that you can change later of course, right?

[00:20:40]And you can do the same thing for IPv6.

[00:20:43]And then we're going to click okay. And there's one more thing that we need to do. So now we need to go to options and then we're going to need to go to boot order. And then what we want to do is we want to tell Proxmox that like hey every time you boot we want you to do use this as the initial boot. So this is number one. So you're basically just going to grab it and then you're going to move it all the way to the top. So and then we're going to check it. So now what that basically means is that when Proxmox put up this VM, it's just going to go through this order and say like, hey, I'm going to check here first. If if there's anything here, I'm going to boot from this drive and that's my boot drive. If there's nothing, then I'm going to go to number two. And if there's nothing in number two, I'm going to go to number three. So we just want to make sure that is checked because this is our main drive. This is the drive that we attached. And then we need to make sure we're moving all the way up to number one. So once we do that, we're just going to click on okay. And then that's pretty much all we need to do to create our VM. So once we do that, we're just now going to go to um our console here and we can start this VM. So ideally if everything works the way it's supposed to work, once we start the VM, the VM is going to boot up. It's going to look at a cloud in it. It's going to load that image and it's going to grab all of the information here from cloud init. And this is the information that it's going to use to apply to the VM. So what we want to do is we want to just click on start and then we're going to go to console and then ideally we should see the booting process kick off and we should see Ubuntu start doing it thing and loading and then once it's fully loaded we should be able to use this username and this password to be able to log into the VM. So ideally even if you're not using this for automation every time now you want to set up a let's say a VM you can just create this as a once you create this as a template you can just clone this and then every time it will use the same username and password and SSH key and DNS or whatever it is that you set here. So we're going to go back to console here and we're going to watch the boot up process. So as you can see things already booted up.

[00:22:41]It's asking me for login. So our login is our username is chromate. So, let's give that a try.

[00:22:47]All right. And then our password is All right. And there you go. And now we'll completely log in. All right. And then we're going to do pseudo SU. That's pretty much it as far as getting the VM up and running. And if we want to change the username, for example, let's say we want to change this username to uh let's say um Kek, right? What we want to do is just click okay. And then we can do something like restart the VM. And once it restarts, it's going to pick up this new username. So, let's give that a try.

[00:23:18]So, we're going to go ahead and uh stop the VM here. You can use here as well, but since I already have this expanded, we're going to right click here and then click on stop and then click on override. That's fine. We're going to completely stop that. And then we're going to say start again, right? And then we're going to let it do its thing.

[00:23:33]And ideally once it boot back up it should be able to uh we should be able to use this um this username here to be able to uh log in. So go back to summary go to console here should be booting back up. So now that it's back up we're going to say kek right and then do the password. There you go. And we're back in. So again with a cloud init um image every time you reboot it's going to go through and then check this and then grab that information from this guy and apply that to the VM before it starts the VM. Right? So that that configuration is the new configuration that's going to be applied to the VM.

[00:24:14]All right. All right. So now the next step that we want to do is we want to convert this guy that we just created which is the temp to a template because what we're going to do is that every time we need to create a new VM um we're going to basically tell our pipeline to use this template and then use that template to be able to create a new VM and then we can apply our configuration changes to that VM as we see fit.

[00:24:35]Convert to template is pretty straightforward. We're going to right click on the VM and I'm going to click on convert template. But you need to make make sure that the VM is completely off before you can convert it to template. So first we want to stop it.

[00:24:45]Right? And that's fine. We're going to click on yes. And I'm going to let it shut down completely. And once it's shut down, we can convert it to template because if you try to convert it to template while the VM is running, it's not going to work. So give it a few, let it do its thing. And then once it's completely off, it's completely off. We can now right click on it and we can say convert to template. And then we can click yes. And that's going to go through the process of converting it to template. So as you can see now I have two templates in this environment. I have the Ubuntu cloud init template which is the template that I'm currently using for the pipeline and then I have this one that we just created which is the one which is Ubuntu cloud temp. So that's pretty much all we need to do when it comes to template. The only other thing that I would say is that just keep in mind of the ID number and the name of the template because these are things that we're going to need uh once we start building our pipeline. But that's for another step. So you don't have to worry about that right now. Once that's fully completed, I now have a reusable cloud in it template that Terraform or Open Tofu will clone every time I spin up a new VM through my pipeline. So the next thing that I needed to do was to set up the API token inside of Proxmox. So this is what basically gives Terraform or Open Tofu the ability to be able to communicate with Proxmox. So we really want to make sure that this is done right or else Gitlab would not be able to communicate with our Proxmox server. Now, the first thing that I I wanted to do is that I wanted to create a dedicated role for this process. Since it's best practice to avoid giving your automation user full admin access, I wanted to create a scope role with only the permission it actually needs. To do that, all I had to do was go to data center and then permission roles and then click on create. You can name this whatever you want, but for me, I'm going to call mine GitLab provision or GitLab pro for short. From there, you can select the privilege you want to assign this role.

[00:26:39]I will show you exactly or you can see exactly which ones I'm using here. But keep in mind that you can adjust this based on how much access you want to grant in your own environment. The next thing that I needed to do was that I needed to create a dedicated user for Terraform. So I head over back to data center and then I clicked on permission and then user and then clicked on add. I created a user and I call it Terraform.

[00:27:01]Again, you can call this user whatever you want. And then you need to make sure or at least I had to make sure that I select realm to Proxmox v authentication server and then set the needed password.

[00:27:12]Now you can add this user to a group and you can add comment to make it easier for you to kind of at a glance be able to know what this user is for. Now again I'm creating a separate user here rather than using an existing admin account because it's always better or best practice to give the automation tool their own scoped credential um rather than using a a user or credential that have a lot of access or much more access than needed to your whole environment like I said earlier. Next I needed to generate the API token. So I went back to data center permission API token and then I clicked add and then I select terraform in your case you can select your user whatever you call your user as the user for this API token and then I give the token a name and add comments again if needed and then I just click add. Now, this part is very important. When the token secret and ID is displayed, you want to make sure you copy the you can copy the ID, too, but you want to definitely make sure you copy the secret immediately. You will not be able to see it once you close this box. And we're definitely going to need it later during our setup. If you do not copy it, you're going to need to generate a new token because you need to copy that secret.

[00:28:26]You need that secret for you to be able to do anything. So, make sure you copy it. Last thing that I need to do now is I basically need to assign permission to both the user and the token so they have the access needed to build the VMs when we start working on our pipeline. And to do that I basically just go to data center again and then click on permission this time around. So you click on the type level permission just click on it and then you just click on add. You will notice you have a few options here including groups, users and token. We are going to set up both the user and the token. I'm going to start up by clicking the user permission and I'm setting the path to root which grant access to the root level. Now the reason I'm doing it this way is because eventually this users is going to need access to create and destroy resources across the environment and I needed to be able to have access to different components of the environment. Again, this is something that you can tie down a little bit as needed. And again, this is something that I might definitely tie down depending on once I start building and start seeing what it needs access to, what it doesn't need access to. I can come back and then try to maybe regenerate things or do things all over again and then tie things down. So, just keep that in mind that this is your decision. You get to decide, hey, I wanted to have access to this things uh or I don't want it to have access to some other things. So, once you get past that, you want to select the user that you created earlier. in my case terraform and then I had to select the role that I created which in my case is getlab provision in your case you can select whatever you call your role and then you want to make sure propagate is checked so that it basically kind of push down the permissions to the resource tree so all of the other things folders install folders kind of are able to get the permissions that you are setting for this particular user once you're done with that selection all you need to do now is just click add you're pretty much going to go through the same exact act process again for your token permission and of course this time you want to make sure you select token permission instead you're going to set the same path or you're going to modify the path as you see fit you're going to select the terapform API token or whatever it is that you call your API token and then you're going to assign the GitLab provision row or whatever it is that you call your row and then of course you're going to check propagate and then you're going to click add. If you find this video helpful at all, please make sure you like and subscribe.

[00:30:46]That helps me out a lot. If you do want to support the channel, you can join Patreon where I will have some exclusive Proxmox content coming soon. I am working on that. I'm working on Proxmox related contents that are specific to Proxmox and deep dive into Proxmox. And of course, if you just want to hang out and just talk tech, come join the Discord community. Link to all of that will be in the description box below.

[00:31:09]All right, so that's it. So basically when it's all done both the user and the token are going to be listed on the permission with the correct role assigned to each that pretty much confirm everything is wired up correctly on the Proxmoke side and I think for now this is pretty much all we need to do on the Proxmoke side. We are also going to need to install the GitLab runners but I want to touch on that a little bit later not right now. All right. So at this point of the build, I now have my GitLab structure in place or my infrastructure as a code structure somewhat in place. I have my cloud in it template is ready to go. And then I have my API token which is fully configured and the Proxmok side of things is starting to look good. But this is where I want to end the video because I'm trying my very best to make this video shorter so it can be much more digestible. So, in the next video, I will head back into GitLab and start working on the repo and the pipeline. I will set up the CI/CD variables, configure the runners, and start wearing everything up together. As always, stay geeking, stay curious, and I will catch you guys on the next one. Peace.