Introduction: Deploying Flowise to the Cloud
In the previous videos, we had a look at some of the fundamentals of creating Flowise applications, but now I want to move on to a topic that many of you have been requesting in the comments, and that is deploying Flowise applications to the cloud.
We will have a look at additional Flowise features in the series, but I get the sense that you guys really want to deploy your applications to a production server at this point. So let's now have a look at the different deployment options as well as some other important settings that you need to consider when running your application online, like security and file persistence.
Without further ado, let's get started.
Exploring Deployment Options & Choosing Render
Let's first have a look at our deployment options. The Flowise documentation is an incredible resource, so if you do get stuck or if you want to try an alternative to what we'll be covering today, I highly recommend having a look at the documentation. I will leave a link to the docs in the description below.
We can see some of the deployment options by clicking on the deployment page in the docs. Because Flowise uses the LangChain.js version of LangChain, we can basically deploy our application to any server that supports Node. A few examples of these are AWS, Azure, Digital Ocean, and Google Cloud Platform. But from my testing, the easiest service to use for deploying Flowise applications is Render. So in this video, we will be having a look at deploying our Flowise application to Render.
Prerequisites: Setting Up Render & GitHub Accounts
So let's talk about the prerequisites.
First, go over to render.com and register your account. Creating an account is free, and if we go to the pricing page, we can see this individual package which is free to use, and this is the package that we'll be using in this demo. The reason why I feel Render is easy to use is we can deploy our projects from GitHub. So go ahead and create your Render account.
We will also be using GitHub, so if you haven't already, go to github.com and create your account. What we want to do is we want to create a copy of the Flowise project and then save it in one of our repositories. We will then use Render to deploy a new instance of Flowise from our GitHub repositories.
Forking the Flowise Repository on GitHub
But first, let's create a copy of Flowise AI. In the description of this video, you will find the link to the Flowise repository. So open that link and then from this page, click on Fork. Fork will create a copy of the Flowise project and install it in our own namespace.
When creating the fork, give the project a name. I will just call it Flowise and ensure that "Copy the main branch only" is ticked. Then click on "Create fork."
We have now created a copy of Flowise and stored it in our own namespace on GitHub. We then don't have to do anything else in GitHub.
Creating & Configuring a Web Service on Render
So after logging into Render, we can now start up a new service, and in our scenario, we want to start up a web services service. So simply click on "New web service." If this is your first time logging in, you should see a setting on the right-hand side for connecting to GitHub. After doing that, you will see a list of your repositories, and in this list, find a repository for Flowise and click on connect.
We can now give our repository a name. I will call mine Flowise. You can then change your region, leave the branch as Main, and leave the root directory as blank.
For the runtime, select Node. For the build command, we'll make one small change: we will call yarn install followed by yarn build. And for the start command, we can leave it as yarn start.
For the instance type, you can go ahead and select the free instance, but for demonstration purposes, I'll actually select the starter package. Don't worry though, you will be able to follow along with this tutorial on the free package, but at the end of the video, I will show you one big benefit of using a paid instance.
Securing Your Flowise Instance
Before we click on "Create Web Service," we first need to click on Advanced. First, let me explain this: after creating this Flowise instance, your Flowise projects will be deployed online. They will be accessible through a URL, and ideally, you don't want to give everyone access to your Flowise dashboard. So what we'll do is we'll set up a username and password to protect our Flowise instance.
To do that, let's click on "Add Environment Variable." For the key value, enter FLOWISE_USERNAME and give it a value, I'll just call it admin. Add another environment variable and call this FLOWISE_PASSWORD and give it a value, I'll just enter password123. We are now done, and we can scroll down to the bottom and click on "Create Web Service."
Deploying and Accessing Your Application
This will take a few minutes to complete, but effectively Render is now copying the files from GitHub, running the build script, and then deploying the compiled project. And after a few minutes, the status of the deployment will change to live, and we can see in the logs the Flowise server is running.
We can now access our Flowise instance by clicking on this URL. And because we set a username and password, our application is now secure. To access our Flowise app, I'll just enter my credentials, and we are now able to use Flowise in the cloud. We can create new chat flows, we can access the marketplace, access tools, as well as the API keys.
Migrating and Testing Individual Chat Flows
Let's go ahead and put our localhost and cloud instance of Flowise next to each other. On the left, we've got the local instance and on the right, our cloud instance.
Let's talk about exporting chat flows. Let's say we've now created a chat flow in our local instance and we now want to import that chat flow into our cloud instance. To copy these chat flows over to the cloud instance is really easy.
Firstly, we can copy all chat flows across in a single go by clicking on Settings > Export Database. This will download a db.json file. All we need to do in the cloud instance is to click on Settings, then Load Database, and select the file. And that will import all of our chat flows in one go.
I'm personally not a fan of doing that since you will override all your chat flows when you do that, and there's a security issue when doing that as well, since all API keys will be copied across as well. So what I like to do instead is to copy the individual chat flows across. Let's have a look at this. I'll select the Chat Model Demo to demonstrate this. In our cloud instance, I'll create a new chat flow. I'll save it and give it the same name, like Chat Model Demo.
All we need to do now is in the local instance, we can click on settings, then export chat flow. This will download the chat flow to our machine. And in the cloud instance, I'll click on settings, then load chat flow, and I'll then select the file that we exported. And this imported our project into the cloud instance.
Take note that the OpenAI API key field is empty, and this is a security precaution. The last thing you want to do is to accidentally copy across an API key that was meant for dev over to production. And this is also the issue that I mentioned by exporting and importing the entire database. When you import the database, it actually copies the API keys across as well. So therefore, I recommend importing and exporting individual chat flows instead.
Let's test out this chat flow. I'll paste in my API key, I'll save this, and let's open up chat. I'll just type in "hello there," and after submitting this, we can see the response coming back from the model. This is working. We now have a chat model running in the cloud.
The Challenge of File Persistence
Let's now talk about file persistence. When we create chat flows, these chat flows are stored in a JSON file on the server. And it's very important to take note that services like Render will delete these files when the server is reset. The server reset can happen for a multitude of reasons. This can be due to maintenance or downtime. The server will also be reset if we deploy the latest version of Flowise to the server. Any changes at a server level will reset the server and we will lose these chat flows, which is not ideal.
Realistically, this hardly ever happens and for prototyping an application, it's perfectly fine. However, for a production app, you want to guarantee that these files will not be deleted.
Solution: Implementing a Persistent Disk on Render
Luckily, Render provides a solution for this. If we go back to the Render dashboard, we can assign a disk to our project. We can use a disk to store application data that needs to be persisted across deploys. Note that this service is only available on one of the paid instances, so if you are using a free instance, you will not have this option. Either way, let's have a look at how we can assign a disk to our project.
We can click on Add Disk. We can then give our disk a name, I'll just call it Flowise. Then for the mount path, enter /opt/render/.flowwise. I'll leave the size as 10 gig and then click on save.
While this is building, we also need to set up additional environment variables to connect our Flowise application to the disk. This will instruct Flowise to store any application data on the disk instead of on the same disk as the project. So let's click on Environment, then click on Add Environment Variable. For the key, enter DATABASE_PATH, and for the value, enter /opt/render/.flowwise. This is the same value we used as the mount path on the disk. We can now save these changes.
We now have our Flowise project running in the cloud, which is accessible through a URL, and our models are now saved on a disk which is persisted even if the server had to be reset.
I hope you found this video useful. Please let me know in the comments which Flowise feature you would want me to cover next. I'll see you in the next one. Bye bye.
