Coder Legion - Recent posts tagged file-server

How to Deploy a Production-Ready File Server on a VPS for Free

Sun, 12 Apr 2026 16:42:31 +0000

Deploying a file server sounds simple.

Making it production-ready is where most developers struggle.

You don’t just need to run the app.
You need to:

keep it running
secure it
handle traffic properly

In this guide, you’ll deploy a real file server using Spring Boot, Nginx, and a VPS.

Start with a ready backend

Instead of building everything from scratch, you can start with a ready file server backend.

https://buildbasekit.com/boilerplates/filora-fs-lite/

It already includes:

file upload APIs
clean project structure
production-ready setup
easy deployment flow (used in this guide)

You can follow this tutorial directly using this boilerplate.

What you’ll build

By the end, you’ll have a file server that:

accepts file uploads
runs continuously with systemd
serves traffic via Nginx
uses HTTPS (SSL)
is protected with a firewall

Prerequisites

VPS (Ubuntu recommended)
Java installed
your Spring Boot jar ready
domain (optional but needed for HTTPS)

1. Prepare your app

Do not hardcode configs.

Use environment variables instead.

Example:


spring.application.name=filorafs
server.port=8080
storage.local.path=/opt/filora/uploads

2. Connect to your VPS


ssh -i your-key.key ubuntu@your-ip

Install dependencies:


sudo apt update && sudo apt upgrade -y
sudo apt install openjdk-21-jdk nginx ufw -y

3. Setup app directory


sudo mkdir -p /opt/filora
sudo chown -R $USER:$USER /opt/filora

Upload your jar:


scp target/app.jar ubuntu@your-ip:/opt/filora/

4. Add environment variables

Create .env file:


DB_PASSWORD=your_password
SERVER_PORT=8080
STORAGE_PATH=/opt/filora/uploads

5. Run app manually


cd /opt/filora
source .env
java -jar app.jar

If it works → move forward.

6. Setup systemd (important)

Create service:


sudo nano /etc/systemd/system/app.service

Paste:


[Unit]
Description=File Server
After=network.target

[Service]
User=ubuntu
WorkingDirectory=/opt/filora
EnvironmentFile=/opt/filora/.env
ExecStart=/usr/bin/java -jar /opt/filora/app.jar
Restart=always

[Install]
WantedBy=multi-user.target

Start service:


sudo systemctl daemon-reload
sudo systemctl enable app
sudo systemctl start app

7. Setup Nginx


sudo nano /etc/nginx/sites-available/app


server {
listen 80;
server_name yourdomain.com;

client_max_body_size 100M;

location / {
    proxy_pass http://localhost:8080;
}

}

Enable:


sudo ln -s /etc/nginx/sites-available/app /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

8. Add HTTPS


sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d yourdomain.com

9. Secure server


sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

Do NOT expose port 8080 publicly.

10. Test everything

upload file
check logs
verify HTTPS

Logs:


journalctl -u app -f

Common mistakes

exposing backend port directly
wrong file permissions
hardcoded configs
skipping HTTPS

Final thoughts

A file server is easy to build.

A production-ready setup is what actually matters.

Once you understand this flow:
build → deploy → proxy → secure

you can deploy almost any backend.

Skip the setup

If you don’t want to do all this manually:

https://buildbasekit.com/boilerplates/filora-fs-lite/

ready backend
file upload APIs
production structure
open source

Build faster. Focus on features.

DevLog 20250806: "Change Version" - File Changes History-Only Version Control for Binary Assets

Wed, 06 Aug 2025 20:37:18 +0000

Overview

cv is a command-line utility I originally used for personal Unreal Engine projects, where proper version control for binary assets was lacking - but I still wanted to track what had changed, at least at the file-system level. It served its purpose well, but after switching from Unreal Engine to Godot, I haven't needed it as much.

For Divooka, as our repository grows and more GUI-related work gets involved, we've increasingly run into the issue of syncing assets across different workstations. Perhaps it's time to bring this old tool back to life.

Demand

The core requirements are simple:

View file change history - ideally alongside corresponding Git commit history.
Compare differences - similar to Git commits, but focused on files, not content.
Synchronize files between machines.

Regarding the third point, we’ve made some adjustments to fit our workflow:

Since we generally focus on one PR at a time and aren’t concerned with previous builds, collaborators mainly need the latest version of assets - not their version history.
Everything must remain simple, maintainable, and cost zero.

Reference Workflow

Based on my previous experience at a game company working on AAA titles, our typical flow involved:

Git for source code
Perforce for asset versioning
Azure DevOps (ADO) for task tracking

Each PR included a GitHub pull request, a corresponding Perforce commit, and an ADO task - usually cross-referenced manually. Every Perforce commit needed to mention which GitHub PR it related to.

The Implementation

Change Version (cv) is a CLI tool that provides quick check against a repo's changes without saving any changed contents. It does so by recording only the update time. The outputs is just like git status, without diff.

This is useful for cases when we DO NOT want to do version control yet would still want the capability to see which files has changed, as in the case of multimedia projects (e.g. game projects).

Usage

The utility supports the following key commands:

init
status
log
commit -m <Message>

Output Folders & Files

.cv

cv saves history inside the .cv folder. File update time is stored as utc.

.cvignore

cv uses a .cvignore file, which shares the same .gitignore format as git, this is used to decide which files cv should consider when issuing status command; Notice we are using a new file name instead of using .gitignore directly - this is to allow the same place having a git repo.

Ignore Rules

I've decided to follow Git's philosophy: everything is considered "important" by default, unless explicitly ignored.

Here’s a basic implementation:

private static string[]? ReadIgnoreRules()
{
string[]? ignoreRules = null;
if (File.Exists(IgnoreFilename))
ignoreRules = File.ReadAllLines(IgnoreFilename)
.Where(l => !string.IsNullOrWhiteSpace(l) && !l.Trim().StartsWith('#'))
.ToArray(); // Skip empty lines and comments
return ignoreRules;
}
private static bool ShouldIgnore(string[] rules, string path)
=> rules.Any(path.StartsWith);

To support more robust wildcard patterns, here’s an upgraded version:

public class IgnoreRule
{
    #region Properties
    private readonly Regex _regex;
    public bool IsNegation { get; }
    #endregion

    #region Construction
    public IgnoreRule(string pattern)
    {
        // Support for !foo to "unignore"
        if (pattern.StartsWith('!'))
        {
            IsNegation = true;
            pattern = pattern[1..];
        }

        // Anchor pattern at repo root if it starts with '/'
        bool anchored = pattern.StartsWith('/');
        if (anchored) 
            pattern = pattern[1..];

        // Convert Git-style glob to regex
        _regex = new Regex(
            "^" +
            Regex.Escape(pattern)
                 .Replace(@"\*\*/", "(@@SLUG@@/)")
                 .Replace(@"\*\*", ".*")
                 .Replace(@"\*", @"[^/]*")
                 .Replace(@"\?", @"[^/]")
                 .Replace("@@SLUG@@", ".*") +
            (anchored ? "$" : "(?:$|/)"),
            RegexOptions.Compiled | RegexOptions.IgnoreCase
        );
    }
    #endregion

    #region Methods
    public bool IsMatch(string path, string repoRoot)
    {
        // If anchored, the path is relative to repoRoot already
        return _regex.IsMatch(path);
    }
    #endregion
}

At this stage, creating a unit test feels essential.

Based on what we have so far, it seems plausible to implement a layer of file transfer service to achieve synching of files between workstations with the help of an intermediate file server.

File Transfer

I talked about the need for a simple file-uploading service just yesterday. Today’s use case is a bit different, as it's strictly internal - we don’t need to support multi-tenant scenarios and we have a fairly accurate idea of our storage needs. Scalability isn’t a major concern.

Server Options

We’re considering ASP.NET Core vs raw TCP sockets for the server:

Concern	Raw TCP / FTP	HTTP (ASP.NET Core)
Reliability	Requires custom framing, retries	Built-in streaming, timeouts, retries
Security	Must implement SSH/SSL manually	HTTPS support out-of-the-box, auth middleware
Chunking/Resume	Reinvent the protocol	Use `Range` headers, tus.io, etc.
Deployment	Requires FTP daemon, ports, etc.	ASP.NET + Kestrel or NGINX
Extensibility	Hard to add endpoints	Minimal APIs, MVC, SignalR, gRPC, DI, etc.

Because we plan to expose the server on the internet, authentication is a must, even if it adds some programming overhead.

Endpoints

To start, simple endpoints suffice for basic usages:

GET /files: Returns a JSON list of all tracked paths.
GET /files/{**path}: Streams the latest copy of a single file.
PUT /files/{**path}: Uploads or overwrites a file.
DELETE /files/{**path} Removes a file.

Testing the Server

Example usage:

# List files
curl -H "X-Api-Key: my-super-secret-key" https://localhost:5001/files

# Upload a file
curl -X PUT -H "X-Api-Key: my-super-secret-key" --data-binary @myfile.txt https://localhost:5001/files/docs/myfile.txt

# Download a file
curl -H "X-Api-Key: my-super-secret-key" https://localhost:5001/files/docs/myfile.txt -o downloaded.txt

Summary

Today, I focused on:

Modernizing and refactoring code; upgrading the framework
Making the program AoT-compatible
Drafting the setup for file sync and server

A few TODO items still need to be addressed before safe syncing can be implemented.

Notably, the server doesn’t need to understand cv or RepoStorage - its only job is to store the latest version of each file. Maintaining accurate timestamps isn’t practical; instead, storing an MD5 checksum is a better way to avoid unnecessary uploads/downloads.

In an ideal world, we’d have a tool tailored perfectly to our needs. In reality, we often find ourselves choosing between overengineered tools that don’t quite fit or having no suitable tool at all.

When the need is real, it’s worth rolling up your sleeves and investing some time in building the right tooling.

References

Wiki: https://wiki.methodox.io/en/Utilities/CLI/cv
Source: https://github.com/MethodoxTech/cv

DevLog 20250804: Simple File Uploading Service (A Request Unfulfilled)

Mon, 04 Aug 2025 19:44:19 +0000

Revision: 001

(This post identifies a problem and is not generating a solution for it yet.)

The Problem

Wouldn’t it be nice if we had a simple way to share our scripts so others could use them immediately?

Pure attempted this with CentralSnippets, which makes it straightforward on the client side (just call something like Pull("Markdown/BuildToC", disableSSL: false)) while relying on GitHub’s PR-based upload process.

For Divooka, we want to achieve something similar - perhaps even simpler. But file sharing inevitably raises three unavoidable concerns:

User authentication
Content management
API or user interface design

User Authentication

When we’re logged in, we often take it for granted - but most platforms require an account to access core functions. For a file-uploading service, the question becomes: which account system should we use?

OAuth can help, but it doesn’t remove the fact that users still need to create an account with the service. That, in turn, means there needs to be an account server.

One possible simplification: GCP’s Firebase Authentication.

Content Management

Once uploaded, files could live on a dedicated file server, or be distributed via a CDN to reduce server load.

Using a CDN is often the simplest long-term approach. However, you still need an intermediate server to communicate with the CDN - you can’t just expose it directly.

Some platforms, like AWS and GCP, offer Signed URLs, which allow controlled access without routing through a central server first.

API or Access Interface

Users might upload files via:

Web forms
HTTP APIs
CLI tools
Dedicated protocols
Client-side libraries

The challenge is deciding which of these methods to support and how to balance simplicity with flexibility.

Accessing

Accessing the files is the easy part: generate a URL, and the file can most likely be downloaded directly over HTTP.

The Ideal Picture

So, what would a general-purpose, ideal file-uploading service look like?

Key aspects might include:

Quick deployment and re-deployment of multiple dedicated file servers
Configurable backends for storage and delivery
Fine-grained access control for uploaded resources

All of which sounds like we’re edging into BaaS (Backend-as-a-Service) territory.