DEV Community: buildbasekit

I’m crash testing FiloraFS-Lite under load (p95, pressure, failures)

buildbasekit — Mon, 27 Apr 2026 08:59:11 +0000

I started running crash tests on FiloraFS-Lite to see how it actually behaves under pressure.

Not benchmarks. Not ideal conditions.
Real stress.

The focus is simple:

where it starts breaking
how early signals show up (p95, pressure)
what fails first under sustained load

What I’m testing right now

increasing RPM until the system shows pressure
tracking how latency (p95) degrades
observing write pressure under continuous load

I already have logs from initial runs.

But instead of rushing conclusions, I’m validating signals properly before sharing anything.

No assumptions. Just observed behavior.

Why this matters

Small-scale tests looked fine.

But real systems don’t fail in clean scenarios.

They fail when:

load spikes
resources get constrained
edge cases stack together

That’s the environment I’m trying to simulate.

What I’ll share next

Once analysis is done, I’ll publish:

what broke first
early warning signals
what actually mattered vs noise
what needs to change

If you’ve done similar crash or stress testing:

What signal usually shows up first for you under load?

Setting Up Auth in 2026: AI Is Fast, But Boilerplates Still Win

buildbasekit — Sat, 18 Apr 2026 16:47:50 +0000

Let’s be honest.

Auth is still one of the most frustrating parts of building a backend.

Even in 2026.

The Reality

Setting up authentication today:

By yourself → 8–15 hours
With AI → 2–3 hours
With a good boilerplate → 2–3 minutes

AI helped a lot.

But it didn’t remove the hardest part.

The Real Problem Isn’t Code

Most devs think auth is about writing code.

It’s not.

It’s about decisions:

JWT or session?
Refresh tokens?
Role system?
Multi-tenant or not?
Middleware structure?
Edge cases?

AI can generate code fast.

But it doesn’t give you a clean, reliable system.

So you still spend hours:

prompting
fixing inconsistencies
restructuring code
debugging flows you didn’t design

That’s where the time goes.

What AI Actually Solves

AI is great at:

generating endpoints
writing controllers
suggesting schemas
speeding up repetitive work

It reduces typing.

But typing was never the bottleneck.

Where Boilerplates Win

A good boilerplate removes:

decision fatigue
architecture mistakes
incomplete flows

You get:

working auth system
clean structure
tested flows
production-ready defaults

And most importantly:

👉 everything already fits together

No guessing. No patching.

AI + Boilerplate > AI Alone

This is the key shift.

Boilerplates don’t compete with AI.

They make AI usable.

With a boilerplate:

AI works inside a solid structure
You extend instead of rebuild
Less debugging, fewer surprises

Without it:

AI gives fragments
You connect everything
Things break in subtle ways

Quick Comparison

Without Boilerplate

Generate auth with AI
Fix token logic
Add middleware
Handle refresh flow
Patch security gaps
Refactor structure

Time: 2–3 hours (best case)

With Boilerplate

Clone repo
Add env values
Start server

Time: 2–3 minutes

The Real Shift in 2026

It’s no longer:

Can you write code fast?

It’s:

Can you start from the right foundation?

Because:

AI speeds up execution
Boilerplates remove setup

And setup is where most time is lost.

When You Should Skip Boilerplates

You don’t need one if:

you’re learning auth deeply
your project is experimental
you enjoy building infra repeatedly

Otherwise, you’re wasting time.

Final Thought

AI made coding faster.

But it didn’t solve:

architecture
structure
system design

That’s why boilerplates still win.

Not because they save minutes.

Because they remove hours of thinking.

Build Faster With a Real Starting Point

If you’re tired of rebuilding auth every time,

start with something that already works.

👉 Check out BuildBaseKit (ready-to-use backend starters)

Auth already set up
Clean structure
RBAC with JWT
Extend, don’t rebuild

Stop Wasting Weeks on Backend Setup

buildbasekit — Mon, 13 Apr 2026 16:53:37 +0000

If you’ve built more than one backend, you’ve seen this before.

You start a new idea.

Then you spend days setting up the same things again:

Auth
Roles and permissions
Multi-tenancy
Database setup
Basic APIs

And suddenly, a week is gone.

No real product. No users.

The real issue

This work isn’t hard.

It’s repetitive.

You’re rebuilding solved problems instead of building something people care about.

Why this slows you down

Early stage is about:

shipping fast
getting feedback
learning quickly

But instead, most time goes into setup.

By the time you're ready, momentum is already low.

A mistake I kept repeating

On one project, I spent around 10 days just setting up backend basics.

When I finished, I had nothing to show.

No users. No feedback.

That’s when it clicked.

I wasn’t building a product.

I was rebuilding infrastructure.

What actually matters

You don’t need a perfect backend.

You need something that:

works
supports real users
lets you move fast

That’s it.

A better approach

Start with a base that already handles:

auth
roles
structure

Then focus on your actual product.

Reality check

Most developers don’t fail because of bad architecture.

They fail because they never ship.

Final thought

Next time you start a project, don’t ask:

“What’s the best setup?”

Ask:

“How fast can I ship something useful?”

If you want to skip backend setup and start faster, try this free:

👉 https://buildbasekit.com/boilerplates/authkit-lite/

JWT vs Session Authentication in Spring Boot: Which One Should You Use?

buildbasekit — Thu, 09 Apr 2026 12:07:25 +0000

Most developers pick JWT or sessions based on tutorials or trends.

That is a mistake.

The wrong choice can:

break scalability
increase complexity
create security issues later

This guide explains how both actually work in real systems and how to choose the right one.

Quick Answer

Use JWT for APIs, microservices, and scalable systems
Use sessions for simple server rendered applications

JWT is stateless and scalable

Sessions are simpler but harder to scale

When This Decision Matters

You need to choose carefully if you are:

building REST APIs
creating login systems
scaling across multiple servers
deciding between stateless vs stateful architecture

Choosing wrong early creates pain later.

What is Session Based Authentication

Session authentication stores user state on the server.

How it works:

server creates a session after login
session data is stored on server
client sends session ID with each request

Key characteristics:

stateful
simple to implement
tightly coupled to server

Problem:

Scaling requires shared storage like Redis.

What is JWT Authentication

JWT is a stateless authentication method.

How it works:

server generates a token
client stores token
token is sent with every request

Key characteristics:

stateless
no server side storage
works well across services

Tradeoff:

Token expiration and revocation are harder.

Key Differences

Feature	Session	JWT
State	Stateful	Stateless
Storage	Server	Client
Scalability	Limited	High
Best For	Monolith apps	APIs and microservices

When to Use Session Authentication

Use sessions if:

you are building server rendered apps
your system is small or medium scale
you want simple session invalidation

Sessions are easier to manage but not built for scale.

When to Use JWT Authentication

Use JWT if:

you are building REST APIs
frontend and backend are separate
you need scalability
you are using microservices

JWT fits modern backend architecture better.

Authentication Flow

Session Flow

user logs in
server creates session
session ID stored in cookie
server validates session on every request

JWT Flow

user logs in
server generates token
client stores token
token sent with each request

Example: JWT Filter in Spring Boot

public class JwtFilter extends OncePerRequestFilter {
    protected void doFilterInternal(HttpServletRequest request,
                                    HttpServletResponse response,
                                    FilterChain chain) {
        // extract token
        // validate token
        // set authentication
    }
}

Common Mistakes

using JWT without handling token expiration
using sessions in distributed systems without shared storage
choosing based on trends instead of requirements

These mistakes cause issues in production.

Related Guides

If you want implementation details:

👉 https://buildbasekit.com/blogs/spring-boot-jwt-authentication/

For real backend architecture:

👉 https://buildbasekit.com/blogs/spring-boot-file-upload-production-guide/

Final Thoughts

There is no universal best option.

JWT is better for:

APIs
distributed systems
scalable backends

Sessions are better for:

simple apps
quick setups
server rendered systems

Choose based on your architecture, not trends.

FAQ

Is JWT more secure than sessions?

No. Security depends on implementation, not the method.

Can JWT be revoked?

Yes, but you need extra mechanisms like token blacklisting.

Should I always use JWT for APIs?

Not always. Simpler systems may work better with sessions.

Build Faster

If you want a ready to use authentication setup:

👉 https://buildbasekit.com/boilerplates/authkit-lite/

Includes:

JWT authentication
role based access
clean architecture

Free and production ready.

How to Store and Serve Files in Spring Boot (Local Storage Guide)

buildbasekit — Thu, 09 Apr 2026 11:45:48 +0000

Storing files in Spring Boot using local storage is easy.

But most implementations break when the project grows.

What starts as a simple upload API quickly turns into:

messy file paths
poor structure
scaling issues

This guide shows how to implement local file storage properly, so your system stays clean and easy to upgrade later.

Quick Insight

Local storage works well for small to medium applications.

But it does not scale in distributed systems.

Use it for simplicity, not long term architecture.

What is Local File Storage in Spring Boot

Local storage means saving uploaded files directly on your server filesystem instead of using cloud storage like S3.

It is simple, fast, and easy to set up.

When You Should Use Local Storage

Local storage is a good choice when:

building small to medium applications
creating internal tools or admin panels
working on MVPs or prototypes
running on a single server

Many projects start here. The key is to structure it properly from the beginning.

Basic File Storage Flow

A typical file handling flow looks like this:

receive file via upload endpoint
validate file
save file to local directory
store file reference in database
serve file via API

Example: File Upload API

@PostMapping("/upload")
public ResponseEntity<?> upload(@RequestParam MultipartFile file) {
    String path = "/uploads/" + file.getOriginalFilename();
    file.transferTo(new File(path));
    return ResponseEntity.ok("Uploaded");
}

This works, but it is not production ready yet.

Where to Store Files

Do not store files inside your source code folders.

Instead:

use a dedicated directory
make the path configurable
keep storage separate from your codebase

Example:

/data/uploads/
/var/app/files/

Serving Files Through API

Never expose raw file paths directly.

Instead:

create a download endpoint
stream files instead of loading fully in memory
set correct content type and headers

This keeps your system secure and efficient.

Keep Storage Logic Separate

Avoid putting everything inside controllers.

Use a clean structure:

Controller → handles request and response
Service → handles file logic
Storage layer → interacts with filesystem

This makes future migration to S3 much easier.

File Naming and Validation

Never trust user input.

Always:

generate unique file names
validate file type
enforce file size limits

Bad validation is a common security risk.

Common Mistakes to Avoid

hardcoding file paths
using original file names directly
skipping validation
mixing storage logic with business logic
serving files without access control

These issues show up later when scaling.

When Local Storage is Enough

Local storage is perfectly fine for:

small to medium apps
internal tools
prototypes
single server deployments

But it becomes a limitation when you scale beyond one server.

Local Storage vs Cloud Storage

Local Storage	Cloud Storage (S3)
simple setup	scalable
low cost	highly available
single server	distributed
hard to scale	easy to scale

If you expect growth, design your system so migration is easy.

Want Production Ready File Upload?

If you want to move beyond local storage and build a scalable system:

👉 https://buildbasekit.com/blogs/spring-boot-file-upload-production-guide/

Final Thoughts

Local storage is simple, but it still needs structure.

If you:

separate concerns
validate inputs
design clean APIs

you can avoid most common problems and upgrade your system later without rewriting everything.

FAQ

Where should I store files in Spring Boot?

Use a dedicated directory outside your source code and make it configurable.

Is local storage good for production?

It works for small applications, but not for distributed systems.

When should I switch to S3?

When you need scalability, multiple servers, or global access.

Related Guides

Build Faster

If you are tired of rebuilding file upload logic:

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

Includes:

file upload system
local storage setup
clean architecture

Free and ready to use.

Spring Boot File Upload: Production Ready System Design Guide

buildbasekit — Thu, 09 Apr 2026 11:41:18 +0000

Building a file upload API in Spring Boot is easy.

Building one that actually works in production is where things break.

Most developers start with a simple controller and local storage. It works fine until:

files get large
traffic increases
security becomes a concern

This guide breaks down what actually matters when designing a production ready file upload system.

Quick Insight

A real file upload system is not just about uploading files.

You need:

security
scalable storage
efficient delivery
clean API structure

Miss one of these, and things start failing in production.

Common Problems with Basic File Upload Systems

Most implementations fail because they ignore real world constraints.

Typical issues:

large uploads crash the server
no validation leads to security risks
local storage fails in distributed setups
messy APIs make scaling painful

If you have seen any of these, your system is not production ready yet.

1. File Upload Security in Spring Boot

Security is not optional.

Every uploaded file should be treated as untrusted input.

What you must do:

validate file type and size
restrict access using authentication (JWT or sessions)
never expose internal file paths

If you have not set up auth yet, start here:

👉 https://buildbasekit.com/blogs/spring-boot-jwt-authentication/

2. Scalable File Storage Strategy (S3 and Cloud)

Local storage works only in early stages.

It breaks when:

you scale horizontally
you deploy across multiple servers

Better approach:

use cloud storage like AWS S3
keep storage separate from application logic
design storage as a pluggable layer

This gives you flexibility without rewriting your system later.

3. File Access and Delivery Optimization

Serving files from your backend is a bottleneck.

Production approach:

use pre signed URLs
stream files instead of loading in memory
use CDN for faster delivery

This reduces load on your server and improves performance.

4. File Metadata and Management

Uploading files is only half the problem.

You also need to manage them.

Store metadata like:

file name
size
owner
storage location

Support:

listing files
deleting files
updating metadata

Without this, your system becomes hard to maintain.

5. Clean File Upload API Design

Bad API design kills scalability.

Keep things separated:

upload endpoint
download endpoint
file management endpoints

Follow clean architecture:

controller layer
service layer
storage abstraction

Avoid mixing responsibilities.

Recommended Architecture

A production ready system usually looks like this:


Client → Controller → Service → Storage Layer → Cloud (S3)
↓
Database (metadata)

Key components:

Controller for request handling
Service for business logic
Storage abstraction (S3 or local)
Database for metadata
Authentication layer

This keeps the system maintainable and scalable.

Common Mistakes to Avoid

storing files directly on the app server
skipping validation
mixing storage logic with business logic
serving files without optimization

These mistakes are the reason most systems fail later.

Final Thoughts

A production ready file upload system is not about adding features.

It is about building the right foundation.

If you design it properly from the start:

you avoid scaling issues
you reduce security risks
you save time later

Most developers underestimate this until they hit real world problems.

Want a Ready to Use Solution?

If you do not want to rebuild this system again and again:

👉 https://buildbasekit.com/boilerplates/filora-fs-pro/

Includes:

authentication setup
S3 integration
clean API structure

Built for real world applications.

Related Guides

Stop Building Messy Discord Bots in Java

buildbasekit — Tue, 31 Mar 2026 08:59:54 +0000

Building a Discord bot in Java is easy.

Keeping it clean as it grows is the hard part.

You start with a few commands, and then:

logic starts mixing with event handling
commands become hard to extend
small changes break multiple features

I’ve seen bots become messy very quickly.

Here’s how to structure it properly from the beginning.

Why Discord bots become hard to maintain

Most bots start small.

But as features grow:

commands get tightly coupled with logic
event handling becomes inconsistent
code duplication increases

Without structure, scaling becomes painful.

Why Discord Bot Structure Matters for Scalability

When structure is ignored early, even small changes require touching multiple parts of the codebase.

That’s when development slows down.

commands become tightly coupled with logic
event handling becomes inconsistent
features are harder to extend
debugging takes longer than expected

Core Components of a Scalable Discord Bot (Java JDA)

A scalable Discord bot should have clear separation between different responsibilities. Even a simple bot benefits from a structured approach.

command layer to handle slash commands and inputs
event listeners to react to Discord events
service layer for business logic
configuration layer for environment variables and setup

How a Discord Bot Works in JDA (Step by Step)

Understanding the flow helps you design a clean and predictable structure.

User triggers a command or event in Discord
JDA listener receives the event
Command handler processes input
Service layer executes logic
Response is sent back to Discord

If these responsibilities are not clearly separated, your bot quickly becomes difficult to maintain.

Best practice: separate commands and business logic

A common mistake is putting all logic inside command handlers.

It works at first, but becomes hard to maintain as features grow.

A better approach is:

commands handle input and response
services handle actual logic
listeners react to events independently


// bad: logic inside command
public void execute(CommandEvent event) {
    if(event.getName().equals("ping")) {
        event.reply("Pong");
        // business logic mixed here
    }
}

Design Your Discord Bot for Scalability and Extension

Your bot should be easy to extend without rewriting existing code. This means organizing features in a modular way.

group related commands into modules
keep shared logic reusable
avoid hardcoded values in logic

Recommended project structure

This structure keeps your Discord bot modular and easy to scale as features grow.


src/
 ├── commands/
 ├── listeners/
 ├── service/
 ├── config/
 └── utils/

If you don’t want to set this up from scratch:

👉 https://buildbasekit.com/boilerplates/basely/

It includes a clean Discord bot structure built with JDA.

Common mistakes to avoid

putting all code in a single package
mixing event handling with business logic
no clear naming or structure for commands
duplicating logic across different commands

Common symptom

Adding a new command requires modifying multiple parts of the codebase.

Without vs with proper structure

Without structure

logic inside command handlers
hard to scale features
duplicate code
messy event handling

With structure

clean separation of layers
easy to extend commands
reusable logic
predictable architecture

Final thoughts

Discord bots don’t become complex because of features.

They become complex because of poor structure.

If you separate commands, events, and logic early, your bot stays easy to extend as it grows.

Want a clean Discord bot setup without rebuilding everything?

I built a minimal Java boilerplate using JDA with:

proper command and event separation
clean service layer
scalable structure

👉 https://buildbasekit.com/boilerplates/basely/

Use it as a starting point instead of building your bot structure from scratch.

How to Build and Deploy a Java Discord Bot Using Spring Boot

Build a production-ready Discord bot using Java 21, Spring Boot, and JDA. Includes project structure, deployment, and best practices.

Stop Making These File Upload Mistakes in Spring Boot

buildbasekit — Tue, 31 Mar 2026 08:43:15 +0000

File upload in Spring Boot looks simple… until it starts breaking.

At first, it’s just one endpoint.

Then suddenly:

file logic spreads across your codebase
validation is inconsistent
storage becomes hard to change

I’ve seen this turn messy very quickly.

Here are the most common mistakes and how to avoid them.

Why file upload implementations go wrong

File upload is deceptively simple.

But as soon as you add:

validation
storage
file retrieval

the logic starts spreading across multiple layers.

Without structure, it becomes hard to maintain.

How File Upload Works in Spring Boot (Step by Step)

Understanding the flow helps you avoid most implementation mistakes.

Client sends file using multipart request
Controller receives the file
Service validates and processes it
Storage layer saves the file
API returns file reference or URL

1. Mixing file handling logic in controllers

A common mistake is putting file processing directly inside controllers.

It works at first, but quickly becomes hard to maintain.

Common issues:

file saving logic inside endpoints
manual path handling in controllers
duplicate logic across APIs

Controllers should stay thin. File handling belongs in a service layer.

2. No validation for file size and type

Accepting any file without validation can lead to security risks and performance issues.

uploading extremely large files
accepting unsupported file types
no limits configured for uploads

Always define clear limits and validate file types before storing them.

Recommended Spring Boot File Upload Structure

This structure keeps file upload logic modular and easy to extend as requirements grow.


src/
 ├── controller/
 ├── service/
 ├── storage/
 ├── model/
 └── config/

If you don’t want to build this structure from scratch:

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

It already includes a clean file upload setup with proper separation.

3. Hardcoding file paths

Hardcoded paths make your application difficult to configure and deploy across environments.

fixed local directories in code
no environment-based configuration
difficult to switch storage later

Use configuration properties or environment variables for file storage paths.

Common symptom

You start with one upload endpoint and end up debugging file handling issues across multiple parts of your application.

4. No clear storage abstraction

Many implementations tightly couple file upload logic with storage details. This makes it hard to switch from local storage to cloud.

storage logic mixed with upload logic
no abstraction layer for storage
difficult to extend to S3 or other providers

A separate storage layer makes your system flexible and easier to maintain.

5. Ignoring file naming strategy

Saving files with original names can cause conflicts and unexpected overwrites.

duplicate file names overwrite existing files
no unique identifiers
hard to track files reliably

Use unique naming strategies such as UUIDs to avoid collisions.

Without vs with proper structure

Without structure

file logic inside controllers
hardcoded paths
no validation
difficult to scale

With structure

clean separation of layers
flexible storage system
proper validation
easy to maintain

Final thoughts

File upload is not the problem.

Bad structure is.

If you separate responsibilities and handle validation and storage properly, your system stays clean as it grows.

Want a clean file upload setup without rebuilding it every time?

I built a minimal Spring Boot boilerplate with:

proper service and storage separation
file upload and download endpoints
production-ready structure

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

Use it as a starting point instead of reinventing file upload for every project.

Spring Boot File Upload API (Clean Structure Guide)

Build a Spring Boot file upload API with clean structure. Learn MultipartFile handling, validation, and scalable storage design.

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

Learn how to deploy a scalable file storage backend using Spring Boot. Step by step VPS setup with zero cost.

Stop Overcomplicating File Upload in Spring Boot

buildbasekit — Tue, 31 Mar 2026 08:28:08 +0000

Building a file upload API in Spring Boot looks simple… until it isn’t.

You start with one endpoint, and suddenly:

file paths are scattered everywhere
validation is inconsistent
storage logic leaks into controllers

I’ve seen this turn into a mess very quickly.

In some cases, teams end up rewriting their entire file handling logic.

Here’s how to build it clean from the start.

Why file upload APIs get messy

File upload starts simple, but complexity grows fast:

handling different file types
managing storage paths
adding validation
supporting downloads

Without structure, this logic spreads across your codebase.

Core components of a file upload API

Even a simple setup should include:

upload endpoint to receive files
download endpoint to retrieve files
storage layer (local or cloud)
validation for file size and type

How Spring Boot File Upload Works (Step by Step)

Understanding the flow helps you design the API correctly from the start.

Client sends file using multipart request
Controller receives the file
Service processes and validates it
Storage layer saves the file
API returns file reference or URL

Best Practice: Structure Your Spring Boot File Upload API

One of the biggest mistakes is mixing file handling logic directly into controllers. This makes it harder to change storage strategies later.

A cleaner approach is to separate responsibilities:

controller handles request and response
service handles file processing logic
storage layer manages file saving and retrieval

Recommended project structure


src/
 ├── controller/
 ├── service/
 ├── storage/
 ├── model/
 └── config/

Common mistakes to avoid

storing files without proper naming strategy
not validating file size or type
hardcoding file paths
no separation between upload and storage logic

A better approach

Start simple, but keep structure clear from day one.

This makes it easy to:

switch from local to cloud storage
add authentication later
scale without rewriting everything

Without vs with proper structure

Without structure

file logic inside controllers
hardcoded paths
difficult to switch storage
code duplication

With structure

clean separation of layers
easy to extend and maintain
storage can be swapped
reusable across projects

Conclusion: Build a Clean File Upload API in Spring Boot

File upload APIs do not need to be complicated. With a simple structure and clear separation of concerns, you can build something that is both easy to maintain and easy to extend.

Want a clean file upload setup without rebuilding it every time?

I built a minimal Spring Boot boilerplate with:

clean controller, service, and storage separation
file upload and download endpoints
production-ready structure you can extend

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

Use it as a starting point instead of reinventing file upload for every project.

Spring Boot File Upload Mistakes (Common Issues)

Avoid common file upload mistakes in Spring Boot. Learn validation, storage design, and how to structure clean file upload APIs.

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

Learn how to deploy a scalable file storage backend using Spring Boot. Step by step VPS setup with zero cost.

Stop Making These JWT Mistakes in Spring Boot

buildbasekit — Tue, 31 Mar 2026 07:15:18 +0000

Most JWT authentication setups in Spring Boot work... until they don’t.

You ship fast, everything seems fine, and then:

tokens stop validating
security bugs appear
your code becomes impossible to maintain

I’ve seen this happen multiple times.

Here are the most common mistakes and how to avoid them.

Why JWT mistakes are dangerous

JWT issues are not just bugs.

They can lead to:

unauthorized access
broken authentication flows
hard-to-debug production issues

Fixing structure early saves you from rewriting your auth system later.

JWT makes authentication easy to scale.

But a poor implementation quickly turns into:

fragile security
messy code
hard-to-debug issues

Most problems come from structure, not JWT itself.

How JWT authentication actually works

User logs in with credentials
Server generates a signed token
Client stores the token
Token is sent with every request
Server validates before processing

If any step is poorly implemented, your entire system becomes unreliable.

1. Mixing authentication logic with business logic

One of the most common mistakes is handling authentication directly inside controllers or services that should focus on business functionality.

Common issues:

token parsing inside controllers
manual validation scattered across endpoints
duplicate logic in multiple places

Authentication should be handled in a dedicated layer, separate from business logic.

2. Poor token management

JWT tokens are central to your authentication system. Mismanaging them can lead to serious issues.

Common symptoms:

users randomly logged out
expired tokens still accepted
security vulnerabilities

Tokens should be validated consistently and configured with proper expiration strategies.

Recommended Spring Boot JWT Authentication Structure

This structure keeps JWT handling isolated and easier to secure and maintain.


src/
 ├── controller/
 ├── service/
 ├── security/
 ├── model/
 └── repository/

If you don’t want to build this from scratch:

👉 https://buildbasekit.com/boilerplates/authkit-lite/

It includes a clean JWT setup with proper structure and security practices.

3. Hardcoding secrets and configuration

Storing secrets directly in code is risky and makes your system less secure and harder to manage across environments.

JWT secret keys in source code
environment-specific values hardcoded
no use of environment variables

Always use environment-based configuration for sensitive data.

4. Skipping role-based access control

Authentication alone is not enough. Without proper authorization, your application cannot control what users are allowed to do.

all endpoints accessible after login
no role or permission checks
inconsistent access control logic

Role-based access should be part of your authentication design from the beginning.

5. Overcomplicating the setup

Many implementations introduce unnecessary complexity with multiple filters, configurations, and layers that are difficult to debug.

too many custom filters without clear purpose
confusing security configuration
lack of clear flow for authentication

Keep the setup simple and structured instead of adding complexity early.

Without vs Proper JWT structure

Without structure:

auth logic everywhere
inconsistent validation
security risks
hard to scale

With proper structure:

clean separation
centralized token handling
predictable behavior
easy to maintain

Quick checklist

keep auth separate from business logic
use token expiration
never hardcode secrets
implement role-based access
avoid overcomplicating configuration

Final thoughts

JWT is not the problem.

Bad structure is.

If you keep authentication isolated, handle tokens properly, and avoid overengineering, your system will stay clean and secure as it grows.

Want a clean JWT setup without the mess?

I built a minimal Spring Boot boilerplate with:

proper security layer separation
clean JWT handling
role-based access control
production-ready structure

👉 https://buildbasekit.com/boilerplates/authkit-lite/

You can use it as a starting point instead of rebuilding auth every time.

Spring Boot JWT Authentication (Clean Setup Guide)

Build JWT authentication in Spring Boot with a clean and reusable setup. Learn token handling, security config, and scalable structure.

Stop Rewriting JWT Authentication in Spring Boot (Use This Instead)

buildbasekit — Tue, 31 Mar 2026 06:44:50 +0000

If you’ve implemented authentication in Spring Boot more than once,
you’ve probably rebuilt the same setup every time.

JWT config, Spring Security setup, role handling...

It gets repetitive fast.

Who this is for

This guide is for you if:

you’ve implemented auth more than once
you’re tired of repeating setup
you want a clean and reusable structure

Authentication is one of the first things every backend project needs.

But instead of being a one-time setup,
it often becomes a repeated task.

The real problem is not authentication itself.
It is the lack of a clean structure and reusable foundation.

Why authentication becomes messy

JWT logic mixed into controllers
No clear separation of concerns
Hard to maintain security config
Different setup in every project

What a production ready authentication system needs

User model with roles
Token generation and validation
Secure endpoints
Clear separation of layers

How to implement JWT authentication (step by step)

Step 1: Define user model

Create user entity with roles and credentials.

Step 2: Implement JWT

Handle token generation and validation separately.

Step 3: Configure security

Setup filters and authentication providers.

Step 4: Secure endpoints

Apply role-based access control.

Step 5: Keep logic separate

Do not mix auth with business logic.

JWT Authentication in Spring Boot Explained

JWT (JSON Web Token) is a stateless authentication mechanism widely used in Spring Boot applications.

It allows secure communication between client and server without storing session data.

In a typical setup, the server generates a token after login.
This token is sent with each request and validated before granting access.

Recommended authentication structure


src/
 ├── controller/
 ├── service/
 ├── security/
 ├── model/
 └── repository/

Common mistakes to avoid

Auth logic inside controllers
Hardcoding secrets
Skipping role checks
Copy-paste implementations

How to avoid rebuilding authentication every time

Treat authentication as a reusable module. Use a consistent structure so you can plug it into any project.

Or instead of building this every time, you can start with a ready setup.

Don’t rebuild authentication again

You can implement everything manually

or start with a ready setup.

AuthKit-Lite includes:

JWT authentication
role-based access control
pre-built APIs
clean project structure

👉 https://buildbasekit.com/boilerplates/authkit-lite/

Free and open source

Final thoughts

With the right structure, authentication becomes a one-time effort instead of repeated work.

JWT Mistakes in Spring Boot (Common Issues and Fixes)

Avoid common JWT mistakes in Spring Boot. Learn token validation, security issues, and how to structure authentication properly.

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

buildbasekit — Sun, 22 Mar 2026 13:42:50 +0000

This article walks through deploying a self-hosted file server on a VPS with a clean production setup: build the app, configure environment variables, run it with systemd, place Nginx in front, and secure the server with SSL and a firewall.

Running your own file server is not only about saving on storage costs. It is also about control: you decide where files live, how uploads are handled, what gets exposed publicly, and how the server is secured.

For this guide, we will use a Spring Boot based file server pattern similar to FiloraFS. The exact app name does not matter much here — the deployment flow is what matters. You can apply these steps to most Java backend file services.

What you will build

By the end of this tutorial, you will have a file server that:

accepts file uploads through a backend API
stores files on disk or in a mounted directory
runs continuously on a VPS using systemd
serves traffic through Nginx
uses HTTPS with a free Let’s Encrypt certificate
is protected by a basic firewall setup

Prerequisites

A VPS with Ubuntu 22.04 or similar
Java 21 installed on your local machine and server
Git access to your project repository
A domain name, if you want HTTPS with Nginx
Your application jar built and ready to deploy with FiloraFS-Lite

Grab source code from here →

1. Prepare the application for production

Start by making sure your app has a clean production configuration. Avoid hardcoding secrets or server-specific paths. Use environment variables or a separate production config file instead.

A typical Spring Boot setup for a file server might look like this:

# application-prod.properties
spring.application.name=filorafs
server.port=8080

storage.local.path=/opt/filora/uploads
spring.servlet.multipart.max-file-size=100MB
spring.servlet.multipart.max-request-size=100MB

spring.datasource.url=jdbc:mysql://localhost:3306/filorafs
spring.datasource.username=filora_user
spring.datasource.password=${DB_PASSWORD}

If your project does not use a database, remove the datasource block and keep only the storage and multipart settings.

2. Get a free VPS

For a low-cost test deployment, you can use a free-tier VPS from a cloud provider that supports Linux instances. Any machine with public IP access, SSH access, and enough storage for your files will work.

Once the VPS is ready, download the SSH key or note the login credentials so you can connect securely.

3. Connect to the server and install dependencies

SSH into the server and install the tools required to run your backend.

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

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

If you plan to build the application directly on the server, also install Git and Maven.

sudo apt install git maven -y

4. Upload the jar and create an app directory

Create a clean folder for your application. Keeping the jar, logs, and environment file inside one directory makes maintenance easier.

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

Then copy your jar file into that directory.

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

5. Add environment variables

Put your secrets and server-specific values in a dedicated .env file. This keeps your service config simpler and avoids exposing values in the codebase.

# /opt/filora/.env
DB_PASSWORD=your_db_password
SERVER_PORT=8080
STORAGE_PATH=/opt/filora/uploads

6. Run the app manually first

Before creating a systemd service, verify that the jar starts correctly in the terminal.

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

If the application starts without errors, you are ready to make it persistent.

7. Create a `systemd` service

systemd keeps the file server alive after reboot and restarts it automatically if the process crashes.

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

Paste the following configuration:

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

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

[Install]
WantedBy=multi-user.target

Then enable and start it:

sudo systemctl daemon-reload
sudo systemctl enable filorafs
sudo systemctl start filorafs
sudo systemctl status filorafs

8. Put Nginx in front of the app

Nginx is useful even for a simple backend. It gives you a stable public entry point, handles HTTPS termination, and lets you define upload size limits.

Create a new site config:

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

Example configuration:

server {
    listen 80;
    server_name yourdomain.com;

    client_max_body_size 100M;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Enable the site and reload Nginx:

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

9. Add HTTPS with Let’s Encrypt

If your server is publicly accessible, SSL is not optional. Use Certbot to get a free certificate and let Nginx manage the HTTPS configuration.

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

After setup, Certbot can renew certificates automatically.

10. Lock down the firewall

Use UFW to expose only the ports you actually need.

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

If your backend should never be reached directly, do not expose port 8080 publicly. Let Nginx talk to the app internally on localhost only.

11. Test everything

Once the service is live, test upload, download, and delete flows from your browser or API client.

Check app logs: journalctl -u filorafs -f
Check Nginx logs: sudo tail -f /var/log/nginx/error.log
Confirm HTTPS loads correctly
Try a real file upload and verify the file appears in your storage directory

Common mistakes

Using localhost in production config

Inside a VPS, localhost is still fine for the app itself, but external clients should connect through your domain and Nginx.

Skipping file permissions

Make sure the service user can write to the upload directory, otherwise file storage will fail even if the app starts.

Exposing the app port directly

Let Nginx handle public traffic and keep the backend private whenever possible.

Final thoughts

A file server becomes much easier to manage once the deployment pattern is clean. Build the jar, move it to a VPS, run it with systemd, place Nginx in front, and secure the machine properly. That is the difference between a demo and a usable production setup.

If you are using a starter like FiloraFS, this workflow gives you a reliable path from local development to a real deployed service without unnecessary complexity.

Original Article

This post was originally published on BuildBaseKit.

If you prefer reading on the main site or want updates, check it here:

https://www.buildbasekit.com/blogs/how-to-deploy-a-production-ready-file-server-on-a-vps-for-free/

Published on March 15, 2026.