The moment you do this, you will get a standard set of instructions on how to “link” your code on your development machine to GitLab project. Now login (or signup) to GitLab and create a project.Place this file within the main application folder. The content of your Procfile will be web: gunicorn : where app-name is usually “app”. In our case let us use Gunicorn, the default Python WSGI HTTP server. Procfile usually consists of the web server used to run the application. Create a Procfile which is used by Heroku to declare what commands are run by your application on the Heroku platform.Run the command pip freeze > requirements.txt from within the main application folder to catch all the requirements for running your application.Verify that everything is running fine.Create a sample Python Flask application on your machine.Create a Python virtual environment for us to use.I have kept it as simple as possible to get things up and running. This write up is also helpful for someone who is just starting out. The steps here assume you already have a good understanding of Python, Flask, version control, GitLab and Heroku. Here are the steps required to deploy your App hosted in GitLab to Heroku. For better understanding of Continuous Integration and Continuous Development (CI/CD) - For beginners, this setup helps you understand the coding workflow of testing -> version control -> code maintenance -> application deployment.Customising pipelines - With GitLab, we can write our own yaml file and include the libraries required for running our application.Easier code maintenance - With code repository hosting services like GitHub and GitLab, maintenance of code is easy.I was now intrigued.īefore I delve into how I deployed the App, I’d like to explain the benefits of using GitLab or GitHub when you can easily get things done with Heroku Git. I browsed a bit on GitLab and it turned out that apart from helping test and build your project, GitLab CI can also help deploy you App to your hosting infrastructure. I couldn’t find any information or documentation around deploying applications hosted in a GitLab repository to Heroku. I was wondering if I can deploy code directly from my GitLab repository instead of using any of the sources mentioned above. It had been quite a while since I used Heroku. Heroku supports deploying an App from GitHub, Dropbox along with the usual Heroku git. The code of the App was hosted in GitLab. If, heaven forbid, they do get in you’ll have to figure out how to lock them out again without losing too much intellectual property.Recently I came across a challenge to deploy a Python Flask web application to Heroku. You’ll have to worry about cybercriminals from around the globe rattling your server’s virtual door handles to see if there’s any way in. Security wise, operating your private server on a publicly accessible network has some downsides. Personally, I’m lazy, so I like “least future hassle.” In my experience, the path of least future hassle on this is to use and get out of the private gitlab server business. You could probably use a service like AWS or Digital Ocean to run a virtual machine for you for around US$10 per month. Move your private server to a data center with public IP access. Again, it’s hard to offer precise procedures without knowing a lot about your office network. It’s quite a bit larger than building out a private gitlab server. That’s not a small project, especially if you’ve never done it before. Get a virtual private network running, so people with permission can access your private network from afar. Without knowing anything about your office router, it’s hard to offer a precise procedure for doing that. Put that private server on a publicly accessible IP address. In your case, to grant access to your private server from outside your private office network you have some choices: But, we had good reasons for it at the time. Using the public server is so easy I’m sort of kicking myself for wasting time with the private server. We granted access to our third party developers on the server. Instead, I migrated our source repositories from our local gitlab server to private repositories at The migration was flawless. We considered whether we should grant those developers access to our virtual private network. We already had a virtual private network allowing people working from home to get to it.Īnd then, about a month ago, we started working with some third party developers who needed access. It was perfect for us at the time, because we hoped to restrict access to just ourselves. About a year ago I set up a local gitlab server, in our office, on our private network.