DEV Community: jtorbett23

Hosting a Godot Server on Oracle Cloud

jtorbett23 — Mon, 15 Dec 2025 10:42:15 +0000

Introduction

When working on multiplayer projects hosting a server is a key part of being able to share it with others.

In this article we will cover how to host a Godot (4.5.1) Server on an Oracle cloud instance. For this we will cover:

The Godot project
Dockerising a Godot server
Hosting a Godot server to an Oracle instance
Setting up HTTPS with NGINX and letsencrypt
Hosting your client on itch.io

Requirements

Godot 4.5.1
Docker and a Docker account
An Oracle cloud account
- Oracle has websites for each region so pick your closest
An itch.io account
A registered domain
- This is only required if you want HTTPS
- Personally I use GoDaddy

1. The Godot Project

The Godot project that we will host is using Godot 4.5.1 in compatibility mode and Godot's high-level multiplayer, specifically the WebSocketServer. This is because in this tutorial we will be hosting our client on the web.

As for what the project does, it allows players to join and leave a 2D space where they can move around with their connection ids shown above them.

You can find the source code for the project here.

2. Dockerising a Godot server

When dockerising an application it is important to have a clear idea of the steps we would manually take to achieve the same effect. In our case we want to have to have a Linux based version of our game running as a Server.

We can achieve this in the following steps:

Setup a Linux based system to run our Server
```
FROM ubuntu:focal AS build

# Install dependenices to download Godot and templates
RUN apt-get update && apt-get install -y --no-install-recommends \
ca-certificates \
unzip \
wget 
```
For this we are using the smallest ubuntu docker image I could find and then install dependencies to download Godot.
(If you know of a smaller one, let me know in the comments)

Install Godot and the templates required to export projects for Linux

ENV GODOT_VERSION="4.5.1"
# Download Godot and templates
RUN wget https://github.com/godotengine/godot/releases/download/${GODOT_VERSION}-stable/Godot_v${GODOT_VERSION}-stable_linux.x86_64.zip 
RUN wget https://github.com/godotengine/godot/releases/download/${GODOT_VERSION}-stable/Godot_v${GODOT_VERSION}-stable_export_templates.tpz 

# Place Godot files in required folders
RUN mkdir -p ~/.cache ~/.config/godot ~/.local/share/godot/export_templates/${GODOT_VERSION}.stable \
&& unzip Godot_v${GODOT_VERSION}-stable_linux*.zip \
&& mv Godot_v${GODOT_VERSION}-stable_linux*64 /usr/local/bin/godot \
&& unzip Godot_v${GODOT_VERSION}-stable_export_templates.tpz \
&& mv templates/* ~/.local/share/godot/export_templates/${GODOT_VERSION}.stable \
&& rm Godot_v${GODOT_VERSION}-stable_export_templates.tpz Godot_v${GODOT_VERSION}-stable_linux*.zip

Here we use wget to download Godot and the templates for exports from the Godot Github releases.

Export a version of our game for Linux
```
# Create a space to build the executable
RUN mkdir /godotbuildspace
WORKDIR /godotbuildspace

# Copy our Godot project into the container
COPY . . 
ARG EXECUTABLE_NAME
ENV EXPORT_NAME="LinuxServer"
ENV EXECUTABLE_NAME=$EXECUTABLE_NAME

# Export the project in debug or release mode
ENV EXPORT_MODE="debug" 
RUN godot --export-${EXPORT_MODE} ${EXPORT_NAME} ${EXECUTABLE_NAME} --headless
```
With Godot downloaded we can now export the project where:
- EXECUTABLE_NAME: is the name of our final executable
- EXPORT_NAME: is the name of our Linux export in our export_presets.cfg
- EXPORT_MODE: is the type of export release or debug. I recommend at this stage using debug as this will allow you to see logs from print() in your Godot code.
This stage also requires you have setup a Linux export in your export_presets.cfg file. The easiest way to do this is in your Godot editor go to Project -> Export and then Add... -> Linux.

For this export preset we are using Options -> Embed PCK = true and Resources -> Export Mode = Export as dedicated server.
Run the exported version as a Server
```
# Start a new stage to execute the exectuable as we do not need the Godot files anymore
FROM ubuntu:focal

ARG EXECUTABLE_NAME
ENV EXECUTABLE_NAME=$EXECUTABLE_NAME
COPY --from=build /godotbuildspace/ ./
EXPOSE 6069/tcp
EXPOSE 6069/udp
CMD ["sh", "-c", "./${EXECUTABLE_NAME} --headless -s"]
```
Finally we run the created executable. For this tutorial:
- Port 6069 is used, as it is defined as the port the client will connect to here, and will require tcp and udp connections.
- We run with the flag --headless as this runs Godot without visual elements, which the server will not require.
- We run with the flag -s as this is how in this project we tell our Godot project to run as a server not a client, the code of this can be seen here.

Now with this file we can build the container with docker build -t mutliplayer-hosting-tutorial-server . and run it with docker run -d -p 6069:6069 -p 6069:6069/udp mutliplayer-hosting-tutorial-server. However, if you do want to use this for local development I recommend using docker-compose.

For later steps we will need to push the image to our docker account so we can pull it on the Oracle instance.

docker build -t <Your Docker Username>/mutliplayer-hosting-tutorial-server .
docker push <Your Docker Username>/mutliplayer-hosting-tutorial-server

You can find the full Dockerfile here.

3. Hosting a Godot server to an Oracle instance

We are going to use Oracle for hosting our server as you can get two instances for free.

Create the Oracle Instance

Start by going to the instances section in Oracle Cloud and create a new instance.

For this we are using Canonical Ubuntu 20.04 image and VM.Standard.E2.1.Micro shape.

Make sure to download your private and public key for SSH.

You can leave all the other settings as default.
Setup Port Connections

Our server will be communicating on port 6069 on both tcp and udp, so we need to allow connections on those ports.

For this we need to change our subnet rules to allow this traffic. These subnet rules can be changed for your instance by:
- Selecting your instance
- Going to the networking tab and selecting the subnet
- Then add a new one:
Download docker and run container

To connect to our server for our local machine we will use the ssh key we downloaded earlier. This can be done with the following command in your terminal:
```
ssh -i <Path to your .key file> ubuntu@<Public IP of your instance>
```
Now on the machine we need to first update the package installer apt and then install docker.
```
sudo apt update
sudo apt install docker.io
```
Then download your published image and run it.
```
sudo docker pull <Your Docker username>/mutliplayer-hosting-tutorial-server
sudo docker run -d -p 6069:6069 -p 6069:6069/udp <Your Docker username>/mutliplayer-hosting-tutorial-server
```
Now we can connect from our local client by updating 127.0.0.1 to the public IP address of your server here.

4. Setting up HTTPS with NGINX and letsencrypt

We want to setup HTTPS as the current HTTP setup will work for local development builds of your Godot client if we want to host our client on itch.io we will require a secure connection to communicate with our server.

Currently we are using a websocket connection with ws:// and we will need to use a secure websocket connection with wss:// from a trusted domain meaning we cannot self sign the connection.

To get that secured signed connection we will be using letsencrypt which requires a registered domain to sign our connection as secure.

Security list updates

With the HTTPS setup we will not be using connection on a the port 6069 directly but instead traffic from the standard HTTPS port 443 will be forwarded to it. This means we can update our security list for the subnet removing 6069 and adding 80 and 443:
Point your domain to IP of server

For this tutorial we will be getting our domain from GoDaddy, you can pick up a cheap domain for year for cheap if you do not mind what the name of that domain will be.

With a domain we need to now setup a A Record, this points our domain to the Public IP address of our server.

This record will point traffic for the sub-domain multiplayer-tutorial for the domain to the public IP address of the server, such that multiplayer-tutorial.<Domain name> will go to the servers public IP address.

Add a NGINX to server

Now we have our domain setup we need to handle requests coming to that domain and make sure any HTTP connections get redirection to HTTPS.

sudo apt install nginx
# Verify that nginx is now running
sudo service nginx status

Now we want to update our nginx config to send any traffic at the domain we defined to our Godot server. You can find the nginx config file at /etc/nginx/nginx.conf, in this tutorial we will just directly edit this file.

# Open the config
sudo nano /etc/nginx/nginx.conf

We will then add the following server block to the http block:

http {
  server {
    server_name  <Your subdomain>.<Your domain>;
    location / {
    # redirect all HTTP traffic to localhost:6069
    proxy_pass http://localhost:6069;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    # WebSocket support
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    }
 }
...
}

This will forward traffic for your domain setup to port 6069 and make use of websockets for that connection. We can can then validate the changes with the following:

# Check the file syntax
sudo nginx -t
# Restart the server
service nginx restart

Add lets encrypt

For this we will need to add a firewall rule to allow letsencrypt to verify our server:

sudo iptables -L --line-numbers
#OUTPUT
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
2    ACCEPT     icmp --  anywhere             anywhere
3    ACCEPT     all  --  anywhere             anywhere
4    ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:ssh
5    REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

We need to add in a line before the REJECT for traffic on port 80 for letsencrypt and port 443 to allow traffic on a secure connection:

sudo iptables -I INPUT 5 -m state --state NEW -p tcp --dport 80 -j ACCEPT
sudo iptables -I INPUT 5 -m state --state NEW -p tcp --dport 443 -j ACCEPT
# Save the changes
sudo netfilter-persistent save

Now we can run certbot, the a cli used for letsencrypt, to verify our domain and update our nginx config.

sudo apt-get install certbot python3-certbot-nginx
sudo certbot --nginx -d <Your Subdomain>.<Your Domain>

Make sure to select option 2 to redirect traffic to HTTPS.

This should result in 2 server blocks /etc/nginx/nginx.conf:

server {
    server_name  <Your subdomain>.<Your Domain>;
    location / {
    # redirect all HTTP traffic to localhost:6069
    proxy_pass http://localhost:6069;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    # WebSocket support
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
   }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/<Your subdomain>.<Your Domain>/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/<Your subdomain>.<Your Domain>/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

...
server {
    if ($host = <Your subdomain>.<Your Domain>) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    server_name  <Your subdomain>.<Your Domain>;
    listen 80;
    return 404; # managed by Certbot
}
...

Note: If certbot fails here, retry after an hour as most DNS records (like the A record we setup) normally take an hour (but can take up to 48 hours) to propagate.

With this we now have an HTTPS connection we can use for websockets for our domain. Our connection will only stay certified for ~45 days through letscencrypt and will require refreshing our certification, for this I recommend setting up a CRON job on your instance to automate this.

5. Hosting your client on itch.io

With our server now running with a secure connection itch.io will allow the client we upload to it to connect.

To upload our client to the web we first need to export it in Godot as a HTML project. For this make sure to name export the .html file as index.html as itch.io requires this.

This will create a folder with your exported project, which then needs to be compressed to a zip folder.

With your compressed client folder, create a project on itch.io and upload it. Make sure to select your project as HTML.

Finally you can run your web clients, in two tabs and should see two players.

Conclusion

With this you should be able to host your Godot servers for only the cost of a domain name. This is great for hobbyist projects, testing and game jams. I hope this allows you to create more multiplayer projects.

Render & Github Actions

jtorbett23 — Wed, 26 Mar 2025 17:24:12 +0000

Introduction

In this tutorial we will cover:

Hosting an API on render.
Using Github actions to run our tests prior to deploying to render.

Prerequisites:

Github account & how to push code to it
Render account (this can be a free account)
Pipenv

The API being hosted

For this tutorial I will be using a example fastapi API written with Python 3.13.0.

Feel free to fork from the tutorial-start branch if you wish to follow along.

If you wish to use your own API the general steps will be the same but make sure that both Render and Github Actions have support for it.

The project is a simple API that outputs Hello World and has 3 commands:

pipenv run dev to run the API locally for development
pipenv run prod to run the API in production context e.g when hosted on Render
pipenv run test to run the tests for the API.

Hosting an API on render

On your Render dashboard create a new Web Service.
Select your newly created Github project. You will need to setup a connection to Github for Render via this guide.
Update the configuration for your programming language version to match the version of your project.

For Python we need to set the PYTHON_VERSION to3.13.0 using an Environment Variable.
Update the Build Command which will install our project dependencies on Render.

For this project it will be pipenv install. We do not required the dev dependencies here as tests will be run on Github Actions.
Update the Start Command which will be run to start up our API on render.

For this project it will be pipenv run prod
After the deployment is complete visit url for the website to see Hello World.

With the current setup as we push new changes to Github it will trigger deployments to Render automatically via deploy hooks.

Try updating the message to {"message": "Hello World Again!"} in main.py and push to Github to see this in effect.

Using Github actions to run our tests prior to deploying to render

Now we have our tests we can run use Github Actions to run our tests and only deploy to render if they pass.

Disable the current auto-deploy on Render by setting "Auto Deploy" to "No" in the settings of your Render project.
Add Github Actions script to the project at github/workflows/ci.yml.

This script has two stages:
- test: this will install the dependencies for running your tests and run them
- deploy: this will deploy your code (if on main) to render
You should see your tests execute fine but it fails to deploy. This is because we still need to add the RENDER_DEPLOY_HOOK_URL.

Add RENDER_DEPLOY_HOOK_URL to the secrets for Github actions

In the setting of your Render project find the Deploy Hook.

Copy the value of this as a new repository secret for Github Actions, this is found at Settings -> Secrets and variables -> Actions.
Try updating the message to {"message": "Hello World Again with Github Actions!"} but before pushing make sure your tests pass locally via pipenv run test.

Conclusion

Congratulations you have now successfully setup a CI/CD pipeline via Github Actions deploying to Render.

Completed Github Project

Live url - As this is hosted via the free version of Render it may require a minute to startup if it has been idle.

React + Gitlab Pages

jtorbett23 — Tue, 26 Jan 2021 17:52:40 +0000

Introduction

In this tutorial we will be showing you how to deploy a react application with a Gitlab deployment pipeline to Gitlab pages.

Prerequisites

For this tutorial you will need to have the following setup

Github Account - https://github.com/join
Gitlab Account - https://gitlab.com/users/sign_up
git - https://git-scm.com/downloads
node and npm - https://nodejs.org/en/download/

Check git, node & npm have installed properly with:

git --version

node --version

npm --version

Creating our react app

In a directory of your choice create a react app with the following command

npx create-react-app gitlab-pages-react-example

(Feel free to change gitlab-pages-react-example to whatever name you desire)

Enter your new react project folder

cd gitlab-pages-react-example

You can use npm start to check your project runs properly and you should see the following at http://localhost:3000

Upload your react app to Github

Create an empty public repository on Github. Then to your local react project and enter these commands to push your code to Github

git remote add origin https://github.com/jtorbett23/gitlab-pages-react-example.git

(You will need to replace https://github.com/jtorbett23/gitlab-pages-react-example.git with the link to your repository)

git push -u origin master

You should now see your react application on your Github repository:

Linking Gitlab and Github

Login to your Gitlab account and create a new project choosing "Run CI/CD for external repository" selecting the repo we created earlier

Once created open your project and go to Settings > General > Visibility, project features, permissions. Then check that Gitlab pages is allowed

Creating our deployment pipeline

For gitlab to create a pipeline to deploy code it requires a
.gitlab-ci.yml file at the root level of project.
(Read more gitlab yaml here - https://docs.gitlab.com/ee/ci/yaml/)

Here is the .gitlab-ci.yml we will be starting with:

image: node

pages:
  stage: deploy
  cache:
    paths:
      - node_modules/
  script:
    - npm install
    - npm run build
    - rm -rf public
    - cp build/index.html build/404.html
    - mv build public
  artifacts:
    paths:
      - public
  only:
    - master

Images

image: node defines node as the type of image that docker will use, allowing use to access npm easily.

Note: if you require a specific node version that can be specified by adding :NODE-VERSION e.g image: node:10.16.3

Stages

pages:
  stage: deploy

This setups a stage for our pipeline, in which we can execute various scripts. For Gitlab pages we need to name this stage "pages" so it deploys content to the correct place.

Caching

cache:
    paths:
      - node_modules/

Caches our node_modules so we don't need to download dependencies every time we run our pipeline.

Scripts

scripts: allows use to run scripts through a terminal

npm install first installs/updates our dependencies
npm run build the builds our project into a build folder
rm -rf public will remove the public folder as we need to use the namespace public to help Gitlab pages recognise our site content
cp build/index.html build/404.html as react is a single page app we set the 404 page to a copy of our index.html to handle errors through index.html
mv build public copy the built project from build to public to allow Gitlab pages to recognise it once deployed

Artifacts

artifacts:
    paths:
      - public

Artifacts are the output of a pipeline stage and we output our public folder holding our built site.

Restricting pipeline stages

  only:
    - master

only lets us set what code branches of project will run this pipeline stage, it is set to master so we don't push development code to our site.

Deploying to Gitlab pages

Once your .gitlab-ci.yml has been pushed to your Github repo Gitlab will sync these changes and run a pipeline based off it.

Your root folder should look like:

-public
-src
-.gitignore
-.gitlab-ci.yml
-package-lock.json
-package.json

On Gitlab navigate to CI/CD > Pipelines and you should see a pipeline has been triggered. Once your pipeline is completed it should look like this:

After your pipeline is complete you will be able to view your site by navigating to Settings > Pages and clicking the url under "Access pages"

Your page should look like this:

Note: we are now have the padlock so are using https

If you instead just get a white page, you will need to edit your package.json and add the "homepage" attribute. For my project my url is https://jtorbett23.gitlab.io/gitlab-pages-react-example/, so i will need to set my homepage as "gitlab-pages-react-example".

{
  "homepage": "gitlab-pages-react-example",
  "name": "gitlab-pages-react-example",
  "version": "0.1.0",
...

You will need to wait for new pipeline to successfully run before seeing the changes.

Deploying a change from our local machine

Now let's make a change to locally to see if updates our site automatically.

Change the text in src/App.js from

<p>
  Edit <code>src/App.js</code> and save to reload.
</p>

to whatever you would like e.g

<p>
  Deployment pipeline is working :)
</p>

Push these changes and it should trigger your deployment pipeline. After it has finished you should see your changes on Gitlab Pages

Improving our pipeline

Currently our pipeline only consists of a single step which means when we are developing further down the line it will be hard to know why our pipeline is failing.

So we are going to separate our pipeline into three stages: build, test and deploy.

Build

build:
  stage: build
  cache:
    paths:
      - node_modules/
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - build

Here we install and cache our dependencies and then build the project outputted as an artifact to be accessible by other stages.

Test

test:
  stage: test
  cache:
    paths:
      - node_modules/
    policy: pull
  script:
    - npm run test

Here we use the cached dependencies through the policy: pull to run our test scripts.

For this stage we will also need to update test script in the package.json to make sure it finds all our test scripts.

...
 "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --watchAll=false",
    "eject": "react-scripts eject"
  }
...

This is done by adding the option --watchAll=false.

Deployment

pages:
  stage: deploy
  dependencies: 
    - build
  script:
    - rm -rf public
    - cp build/index.html build/404.html
    - mv build public
  artifacts:
    paths:
      - public

Here we take the built project from the build stage's artifact and then deploy the code as normal.

Here is the final .gitlab-ci.yml:

image: node

build:
  stage: build
  cache:
    paths:
      - node_modules/
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - build

test:
  stage: test
  cache:
    paths:
      - node_modules/
    policy: pull
  script:
    - npm run test

pages:
  stage: deploy
  dependencies: 
    - build
  script:
    - rm -rf public
    - cp build/index.html build/404.html
    - mv build public
  artifacts:
    paths:
      - public
  only:
    - master

Wrap up

You have now learned how to deploy a react application from Github to Gitlab pages using Gitlab CI/CD pipeline.

Here are the links for the completed project for reference:
Github - https://github.com/jtorbett23/gitlab-pages-react-example
Gitlab - https://gitlab.com/jtorbett23/gitlab-pages-react-example
Gitlab Pages url - https://jtorbett23.gitlab.io/gitlab-pages-react-example/