Now that we have our application deployed, I want to take some time to discuss the limitations and architectural considerations that come with our current setup.

We deployed our application using Hatchbox on a Digital Ocean server. I believe this is the ideal setup for an SQLite-backed Rails application for several reasons.

Why Digital Ocean is Ideal for SQLite on Rails

The first major reason is the need for a permanent file system.

Platforms like Heroku, which use ephemeral file systems, are not suitable for an SQLite-backed application because the database file would be lost on every deploy. However, this limitation extends beyond Heroku—many platform-as-a-service (PaaS) providers, such as Render, only offer persistent storage as a network-attached service.

While SQLite can work with network-attached storage, SQLite itself recommends against it. The reason? These networked file systems introduce unpredictability in how data is read and written, leading to potentially complex edge cases that are difficult to debug.

For an ideal SQLite deployment, you want a standard file system running on a standard operating system within a single-machine setup. While network-attached storage can be used, it’s likely to introduce unwanted complexities that could affect database stability and performance.

The Benefits of Owning Your Infrastructure

Given these constraints, owning your operating system is the best way forward.

This is why I prefer renting machines from Hetzner, Digital Ocean, or other cloud providers. With a dedicated server, I get:

• A normal machine with a predictable operating system
• Full access to the permanent file system
• Complete control over server configuration and deployment

This setup ensures maximum stability for an SQLite-backed Rails application, minimizing potential risks from platform restrictions or network storage issues.

Considerations Around Scaling

We have chosen a single-machine deployment, which offers several advantages in terms of operational simplicity:

• We know exactly what needs to be installed on one machine
• We have one environment to configure, maintain, and monitor
• It allows local development to closely match production, reducing inconsistencies

However, this single-server setup does come with trade-offs.

The most important trade-off is the need to accept and plan for scheduled downtime.

Why Scheduled Downtime is Essential

While unscheduled downtime is bad and should be avoided, that does not mean all downtime is bad. In fact, in a single-machine deployment, some level of planned downtime is necessary for making foundational updates to the application.

The simplest and most effective approach is to:

1. Notify users in advance about upcoming maintenance
2. Schedule a fixed window of downtime
3. Put the application into maintenance mode

Hatchbox makes this easy by providing a built-in maintenance mode, so you don’t have to set up anything extra to handle planned downtime.

By embracing scheduled maintenance, we can ensure that our single-machine deployment remains stable, while making essential updates in a controlled and predictable manner.