Hosting BOSS projects - Revision history

Pm2022: Pm2022 moved page BOSS/Hosting to Hosting BOSS projects

2026-08-26T08:14:52Z

Pm2022 moved page BOSS/Hosting to Hosting BOSS projects

← Older revision	Revision as of 08:14, 26 August 2026
(No difference)

Pm2022: rewrite in first person, remove fluff, cat

2026-08-26T08:14:32Z

rewrite in first person, remove fluff, cat

← Older revision		Revision as of 08:14, 26 August 2026
Line 1:		Line 1:
	~~Our approach to hosting is that you will~~ be able to host any low-intensity applications ~~(this should encompass anything we are doing)~~ for free. However, just so you do not get scammed, if any service shouts it from the roof top that their stuff is free, it’s probably a scam unless it’s a legitimate big business who can afford to do it.		You should be able to host any low-intensity applications for free using one of the [[:Category:BOSS hosting methods\|recommended hosting methods]], if you follow the instructions in this page. However, just so you do not get scammed, if any service shouts it from the roof top that their stuff is free, it’s probably a scam unless it’s a legitimate big business who can afford to do it.

	== Application structure ==		== Application structure ==
Line 5:		Line 5:
	The structure of your application is extremely important to be able to host stuff for free.		The structure of your application is extremely important to be able to host stuff for free.

	You will want to split it up into three parts: frontend, backend and some sort of storage (e.g. database), this allows each part to be hosted separately and at lower costs. If you do not need a certain part, for example storage, you can just not host anything.		You will want to split it up into three parts: frontend, backend and some sort of storage (e.g. database), this allows each part to be hosted separately and at lower costs. If you do not need a certain part, for example storage, you can just not host anything for it.

	=== Frontend ===		=== Frontend ===
Line 13:		Line 13:
	}}		}}

	For the frontend, this should always just be a static page. This can use any of the [[BOSS/Hosting/Pages\|“Pages” products]], e.g. GitHub, GitLab, [[BOSS/Hosting/Cloudflare\|Cloudflare Pages]] (which are all free). ~~For BathCS, we use~~ Cloudflare pages ~~as we do not store our code on a~~ GitLab instance ~~that supports~~ pages.		For the frontend, this should always just be a static page. This can use any of the [[BOSS/Hosting/Pages\|“Pages” products]], e.g. GitHub, GitLab, [[BOSS/Hosting/Cloudflare\|Cloudflare Pages]] (which are all free). BOSS uses Cloudflare pages because their GitLab instance does not support pages.

	~~By “static”, we mean~~ that requesting a URL, it will always return the same JavaScript and HTML (this is a bit more of a loose definition than what it actually means as we can get dynamic features with an API).		A static site means that requesting a URL, it will always return the same JavaScript and HTML (this is a bit more of a loose definition than what it actually means as we can get dynamic features with an API).

	~~A consideration you may want to take~~ is to integrate the frontend into the same system as the backend, which usually means you can host it with one docker container which means an easier deployment and allows for (easier) dynamic pages.		Another option is to integrate the frontend into the same system as the backend, which usually means you can host it with one docker container which means an easier deployment and allows for (easier) dynamic pages.

	However if you are using something like Svelte or React, it can be quite hard to get pages well optimised for loading.		However if you are using something like Svelte or React, it can be quite hard to get pages well optimised for loading.

	As a side note, it is becoming quite common nowadays to have authenticated areas (which require dynamic pages and access control) on a different website entirely (normally under a subdomain) e.g. <code>scaleway.com</code> ~~and~~ <code>console.scaleway.com</code>. However, this is only recommended for big and complicated projects ~~(which we want to stay away from)~~.		As a side note, it is becoming quite common nowadays to have authenticated areas (which require dynamic pages and access control) on a different website entirely (normally under a subdomain) e.g. <code>scaleway.com</code> is public while <code>console.scaleway.com</code> is restricted. However, this is only recommended for big and complicated projects.

	Wordpress, Wix or Squarespace are a big no-no.		Wordpress, Wix or Squarespace are a big no-no for security and pricing reasons.

	=== Backend ===		=== Backend ===

	A backend is usually only needed when you have some sort of storage and mostly acts as a validation layer and stops people from just deleting everything. Please avoid Python and TypeScript/JavaScript or other languages which don’t have runtime validation. ~~This is for your own sanity as trying~~ to implement the level of security which is required is a pain beyond compare.		A backend is usually only needed when you have some sort of storage and mostly acts as a validation layer and stops people from just deleting everything. Please avoid Python and TypeScript/JavaScript or other languages which don’t have runtime type validation. Trying to implement the level of security which is required is a pain beyond compare in those languages.

	~~These~~ should usually be using Docker containers or a serverless architecture (e.g. [[BOSS/Hosting/Cloudflare#Workers\|Cloudflare Workers]]).		The backend should usually be using Docker containers or a serverless architecture (e.g. [[BOSS/Hosting/Cloudflare#Workers\|Cloudflare Workers]]).

	==== Docker containers ====		==== Docker containers ====
Line 54:		Line 54:

	In general just do a refresher course on GDPR.		In general just do a refresher course on GDPR.
			[[Category:Bath Open Source Society]]
	~~== How~~ [[Bath Open Source Society~~\|BOSS~~]] ~~hosts stuff ==~~
	Following try to follow this structure for all applications just to make management a bit easier and to have backup options. But all backends are hosted on our [[BOSS/Hosting/Cluster\|own kubernetes cluster]] found in the university. This kubernetes cluster is hosted within an immutable VM on a server that we manage.

	~~This means that we are able to host (basically) anything we like for free as long as it fits within our resources budget.~~

Hw2210: Update links and information due to our recent cluster

2026-06-04T08:55:59Z

Update links and information due to our recent cluster

← Older revision		Revision as of 08:55, 4 June 2026
Line 29:		Line 29:
	A backend is usually only needed when you have some sort of storage and mostly acts as a validation layer and stops people from just deleting everything. Please avoid Python and TypeScript/JavaScript or other languages which don’t have runtime validation. This is for your own sanity as trying to implement the level of security which is required is a pain beyond compare.		A backend is usually only needed when you have some sort of storage and mostly acts as a validation layer and stops people from just deleting everything. Please avoid Python and TypeScript/JavaScript or other languages which don’t have runtime validation. This is for your own sanity as trying to implement the level of security which is required is a pain beyond compare.

	These should usually be using Docker containers or a serverless architecture (e.g. [[BOSS/Hosting/~~Cloudlfare~~#Workers\|Cloudflare Workers]]).		These should usually be using Docker containers or a serverless architecture (e.g. [[BOSS/Hosting/Cloudflare#Workers\|Cloudflare Workers]]).

	==== Docker containers ====		==== Docker containers ====
Line 36:		Line 36:

	* If you are building a Docker container, please make sure it uses a small base image e.g. alpine (even if you have to install dependencies manually) as nearly all container registries will charge you for hosting large Docker images. If its a compiled language even better.		* If you are building a Docker container, please make sure it uses a small base image e.g. alpine (even if you have to install dependencies manually) as nearly all container registries will charge you for hosting large Docker images. If its a compiled language even better.
	* Due to the usual lack of cache-able information, you want to be hosting as close to the UK as possible which also helps with GDPR stuff (so just don’t host anything in America – which invalidates many free hosting sadly).		* Due to the usual lack of cache-able information, you want to be hosting as close to the UK as possible which also helps with GDPR stuff (so just don’t host anything in America – which invalidates many free hosting options sadly).

	You can host Docker containers for free on [[BOSS/Hosting/Scaleway\|Scaleway]] ~~(recommended) or~~ [[BOSS/Hosting/~~Google Cloud~~\|~~Google Cloud~~]]		You can host Docker containers for free on [[BOSS/Hosting/Scaleway\|Scaleway]] however we host all ours on [[BOSS/Hosting/Cluster\|our own kubernetes cluster]].

	=== Storage ===		=== Storage ===
Line 44:		Line 44:
	This one is the hardest to host for free, but there are free solutions out there if you just stick with the typical database structure (e.g. PostgreSQL).		This one is the hardest to host for free, but there are free solutions out there if you just stick with the typical database structure (e.g. PostgreSQL).

	We do recommend PostgreSQL as it is the standard business practice nowadays~~. However free hosting is much harder to find~~.		We do recommend PostgreSQL as it is the standard business practice nowadays, which we can host on [[BOSS/Hosting/Cluster\|our own kubernetes cluster]].

	An alternative to this is ~~[[BOSS/Hosting/~~MongoDB ~~Atlas\|MongoDB]]~~, whose Atlas program allows you to easily host this for free. However, this is discouraged (and outright shamed if used with TypeScript/JavaScript and Python) due to the issues with validating data before it goes into the database (as it literally just accepts objects).		An alternative to this is MongoDB, whose Atlas program allows you to easily host this for free. However, this is discouraged (and outright shamed if used with TypeScript/JavaScript and Python) due to the issues with validating data before it goes into the database (as it literally just accepts objects).

	==== Required considerations ====		==== Required considerations ====
Line 54:		Line 54:

	In general just do a refresher course on GDPR.		In general just do a refresher course on GDPR.

			== How [[Bath Open Source Society\|BOSS]] hosts stuff ==
			Following try to follow this structure for all applications just to make management a bit easier and to have backup options. But all backends are hosted on our [[BOSS/Hosting/Cluster\|own kubernetes cluster]] found in the university. This kubernetes cluster is hosted within an immutable VM on a server that we manage.

			This means that we are able to host (basically) anything we like for free as long as it fits within our resources budget.

Hw2210: Translate from boss.bathcs.com

2026-06-04T08:31:31Z

Translate from boss.bathcs.com

New page

Our approach to hosting is that you will be able to host any low-intensity applications (this should encompass anything we are doing) for free. However, just so you do not get scammed, if any service shouts it from the roof top that their stuff is free, it’s probably a scam unless it’s a legitimate big business who can afford to do it.

== Application structure ==

The structure of your application is extremely important to be able to host stuff for free.

You will want to split it up into three parts: frontend, backend and some sort of storage (e.g. database), this allows each part to be hosted separately and at lower costs. If you do not need a certain part, for example storage, you can just not host anything.

=== Frontend ===

{{Note|text=
If you can do it as a single static website, do it as a static website.
}}

For the frontend, this should always just be a static page. This can use any of the [[BOSS/Hosting/Pages|“Pages” products]], e.g. GitHub, GitLab, [[BOSS/Hosting/Cloudflare|Cloudflare Pages]] (which are all free). For BathCS, we use Cloudflare pages as we do not store our code on a GitLab instance that supports pages.

By “static”, we mean that requesting a URL, it will always return the same JavaScript and HTML (this is a bit more of a loose definition than what it actually means as we can get dynamic features with an API).

A consideration you may want to take is to integrate the frontend into the same system as the backend, which usually means you can host it with one docker container which means an easier deployment and allows for (easier) dynamic pages.

However if you are using something like Svelte or React, it can be quite hard to get pages well optimised for loading.

As a side note, it is becoming quite common nowadays to have authenticated areas (which require dynamic pages and access control) on a different website entirely (normally under a subdomain) e.g. <code>scaleway.com</code> and <code>console.scaleway.com</code>. However, this is only recommended for big and complicated projects (which we want to stay away from).

Wordpress, Wix or Squarespace are a big no-no.

=== Backend ===

A backend is usually only needed when you have some sort of storage and mostly acts as a validation layer and stops people from just deleting everything. Please avoid Python and TypeScript/JavaScript or other languages which don’t have runtime validation. This is for your own sanity as trying to implement the level of security which is required is a pain beyond compare.

These should usually be using Docker containers or a serverless architecture (e.g. [[BOSS/Hosting/Cloudlfare#Workers|Cloudflare Workers]]).

==== Docker containers ====

You should take a few extra things into consideration when using a Docker container:

* If you are building a Docker container, please make sure it uses a small base image e.g. alpine (even if you have to install dependencies manually) as nearly all container registries will charge you for hosting large Docker images. If its a compiled language even better.
* Due to the usual lack of cache-able information, you want to be hosting as close to the UK as possible which also helps with GDPR stuff (so just don’t host anything in America – which invalidates many free hosting sadly).

You can host Docker containers for free on [[BOSS/Hosting/Scaleway|Scaleway]] (recommended) or [[BOSS/Hosting/Google Cloud|Google Cloud]]

=== Storage ===

This one is the hardest to host for free, but there are free solutions out there if you just stick with the typical database structure (e.g. PostgreSQL).

We do recommend PostgreSQL as it is the standard business practice nowadays. However free hosting is much harder to find.

An alternative to this is [[BOSS/Hosting/MongoDB Atlas|MongoDB]], whose Atlas program allows you to easily host this for free. However, this is discouraged (and outright shamed if used with TypeScript/JavaScript and Python) due to the issues with validating data before it goes into the database (as it literally just accepts objects).

==== Required considerations ====

* Hosting '''MUST''' be in the UK or Europe (due to GDPR)
* Please also consider how much data you need and if you are storing personal, identifiable information as that causes headaches with GDPR.

In general just do a refresher course on GDPR.