Forem: Diogo Viana

Quick Rails Tip: Change Database Adapter

Diogo Viana — Fri, 05 Dec 2025 23:31:35 +0000

The magic command

Rails introduced a command a while back that simplifies database adapter changes.

rails db:system:change --to=postgresql

What does this command do

Updates the Gemfile - Adds/removes the necessary gems
Modifies the database.yml - Configures the new connections
Generates the migrations - Creates the migration files for the new database
Updates the configurations - Adjusts the schema.rb and other files

More practical examples

# Changing from SQLite to PostgreSQL
rails db:system:change --to=postgresql

# Changing to MySQL
rails db:system:change --to=mysql

# Going back to SQLite
rails db:system:change --to=sqlite3

Important considerations

Always backup! - Backup your data before making changes
Test in development - Never test in production
Check data types - Some types may need adjustments
Dependencies - Make sure you have the database installed on your machine (or Dockerfile)

Conclusion

Rails is full of hidden gems, and this is one of them. I think it's super useful, especially when you start a small project with SQLite and then want to migrate to PostgreSQL, for example.

Por que seus pull requests devem ser pequenos

Diogo Viana — Mon, 28 Apr 2025 23:15:37 +0000

Motivação

Tudo começou quando percebi um padrão preocupante no meu trabalho atual: os desenvolvedores demoravam muito mais tempo para revisar PRs grandes. Curioso com essa situação, decidi fazer uma pesquisa(interna) com a equipe para entender melhor o problema. A resposta foi unânime: quando um PR era grande, os desenvolvedores precisavam de um período significativo de tempo para fazer uma revisão adequada, o que significava interromper o trabalho que estavam fazendo. Isso criava um bloqueio muito grande para o autor do PR.

Por outro lado, quando os PRs eram pequenos, a história era completamente diferente. Os desenvolvedores paravam o que estavam fazendo para fazer a revisão rapidamente, mantendo o fluxo de trabalho ágil e eficiente.

Com os resultados em mão, decidimos estabelecer um limite prático: máximo de 15 arquivos alterados por PR. Para monitorar e melhorar essa prática, implementamos uma GitHub Action que adicionava automaticamente um label "too large" em PRs que excediam esse limite. No início, o número de PRs com esse label era alarmante, mas isso nos deu uma métrica clara para acompanhar nossa evolução.

Com o tempo(e muita insistência da minha parte) a equipe começou a se adaptar à nova cultura de PRs pequenos. Hoje, é raro ver um PR com o label "too large", e o processo de revisão flui muito mais suavemente. Esta experiência me mostrou na prática o valor de manter PRs pequenos e focados.

Quais os reais benefícios percebidos?

1. Revisões Mais Rápidas e Eficientes

PRs menores são mais fáceis de revisar. Enquanto um PR grande pode exigir um período de tempo significativo para revisão, PRs pequenos podem ser revisados em intervalos curtos, tornando o processo mais ágil e menos oneroso para os revisores.

2. Maior Qualidade nas Revisões

Com menos código para analisar, os revisores podem se concentrar melhor em potenciais problemas com mais precisão. Em PRs grandes, é comum que pontos importantes passem despercebidos devido à sobrecarga de informações.

3. Menor Probabilidade de Bugs

Mudanças menores são mais fáceis de testar e validar. Tanto o autor quanto o revisor conseguem entender melhor o impacto das alterações, reduzindo a chance de introduzir bugs.

4. Código modular

A necessidade de escrever código em pequenos pedaços naturalmente leva a um design mais modular e desacoplado, pois você é forçado a pensar em como dividir a funcionalidade em partes menores e mais coesas.

Como escrever PRs pequenos

Sempre pense em pré-mudanças, mudanças e pós-mudanças. Em outras palavras, não escreva uma feature completa em UM ÚNICO PR.
Novos arquivos devem ser adicionados separadamente com antecedência se estiverem misturados com outras mudanças.
Separe as refatorações em PRs diferentes.
Escreva código desacoplado que possa ser "deployado" a qualquer momento.

Muita gente trabalha com sistema de tickets(como JIRA) e normalmente as pessoas criam um PR para um ticket, o que pode ser um problema se o ticket for para uma feature grande. O ideal é que você crie vários PRs para um ticket.

Quando PRs grandes são aceitáveis?

Existem algumas situações onde PRs maiores podem ser justificáveis:

Remoção de arquivos inteiros
Mudanças que são intrinsecamente grandes e não podem ser divididas

Conclusão

Manter PRs pequenos não é apenas uma boa prática, é uma estratégia que beneficia toda a equipe. Aumenta a qualidade do código, acelera o processo de revisão e reduz a probabilidade de erros. Embora possa parecer mais trabalhoso no início, os benefícios a longo prazo superam amplamente qualquer esforço adicional.

P.S

Na época em que estávamos fazendo essa mudança lá na empresa, o blog The Pragmatic Engineer escreveu um artigo sobre como usar stacked diffs, que é uma técnica muito boa para escrever PRs pequenos.

Setup Rails Active Storage with Hetzner

Diogo Viana — Fri, 11 Apr 2025 20:07:11 +0000

Introduction

If you don't know what Hetzner is, you're missing out. It is a cloud provider very similar to Digital Ocean, but with incredibly cheap prices. Currently, it's my first choice when it comes to deploying my side projects.

While Hetzner doesn't have as many features as Digital Ocean, they have the important ones. And today I'd like to talk about one in particular, the Object Storage. It's basically a wrapper for AWS S3 with cheap prices and none of the complexity to set up.

So, if you want to try Rails Active Storage with Hetzner, I'm going to show you how easy it is to set up.

Prerequisites

Rails 6.0 or higher
A Hetzner account
Basic understanding of Rails Active Storage

Creating a Bucket
Generating Credentials
Configuring Your Rails Application
Testing Your Configuration
Security Considerations

Creating a Bucket

The first thing you have to do is go to your Hetzner account and create a new bucket, by clicking on Object Storage on the sidebar then "Create Bucket" on the right top corner.

Next, you'll see this modal asking to select location, input a name (this will be important) for your bucket which will be also used as URL. For object lock, you can leave it as disabled, and in visibility, you can select public (read-only).

That's it, the bucket is ready for you to use it. But before you can set up your app to use it, we need to generate credentials, which is also very easy.

Generating Credentials

When you click on your bucket, you'll be redirected to an overview page and in that page, you'll click on "Actions" -> "Generate Credentials". You'll be prompted to input a description for those credentials and that's it. Copy both access key and secret key into a safe place.

Configuring Your Rails Application

The first thing to do is to add the gem aws-sdk-s3 that is basic the client that is going to interact with S3 API.

# add to your gemfile and then run bundle install
gem 'aws-sdk-s3', require: false

Now, we need to save those credentials somewhere in the application. You can either use the dotenv gem, which I don't recommend for secrets, or you can use Rails' built-in credentials system.

I'm going to use Rails' credentials system. Let's use the Rails commands to set the secrets:

bin/rails credentials:edit

Save your keys exactly like this:

hetzner:
  access_key_id: YOUR_ACCESS_KEY
  secret_access_key: YOUR_SECRET_KEY

Now let's edit your config/storage.yml file:

hetzner:
  service: S3 # YES, this is correct! Hetzner is S3 compatible, remember?
  endpoint: https://hel1.your-objectstorage.com # Format: https://<region>.your-objectstorage.com
  access_key_id: <%= Rails.application.credentials.dig(:hetzner, :access_key_id) %>
  secret_access_key: <%= Rails.application.credentials.dig(:hetzner, :secret_access_key) %>
  region: eu-central # if you selected Finland as location
  bucket: <the name you gave your bucket when creating it>

Note: The endpoint URL format varies by region. For example:

Finland: https://hel1.your-objectstorage.com

Germany: https://fsn1.your-objectstorage.com

USA: https://us1.your-objectstorage.com

The last part is to change your config/environments/production.rb file to use the new Hetzner configuration you just added:

# Store uploaded files on the local file system (see config/storage.yml for options).
config.active_storage.service = :hetzner

Testing Your Configuration

To verify your configuration is working correctly, you can use the Rails console:

# Start the Rails console
rails c

# Test the connection
ActiveStorage::Blob.service.exist?("test.txt")

If this returns false (which is expected for a non-existent file), your connection is working properly.

Security Considerations

When using public buckets, consider the following security measures:

Access Control: Even with a public bucket, you can still control access through your application logic.
File Validation: Implement strict file type and size validation in your models.
Expiring URLs: For sensitive files, consider using expiring URLs instead of public access.

Conclusion

That's it! Now all your files uploaded using Active Storage will be stored in your Hetzner bucket. This setup provides a cost-effective alternative to AWS S3 while maintaining compatibility with Rails Active Storage.

For more information, check out:

8 Anos de Alemanha e como isso me mudou

Diogo Viana — Sun, 23 Mar 2025 13:19:37 +0000

No dia 20 de fevereiro de 2025, eu e minha esposa completamos 8 anos na Alemanha. Cheguei aqui com apenas 32 anos e agora sou um quarentão. Nossa filha nasceu aqui em 2018 e hoje fala alemão melhor que nós dois. Aliás, até português ela fala melhor que eu.

Tudo começou em 2016, quando a startup que eu co-fundei faliu. De repente, me vi sem emprego, sem salário e sem saber o que fazer. E isso tudo no meio de um planejamento de casamento.

Jogando bola com os amigos, notei que um deles não tinha comparecido à nossa peladinha semanal. Então perguntei: "Ué, cadê o Rafael?". A resposta foi simples e direta: "Mudou para a Polônia". Mas como assim? Semana passada ele estava lá jogando com a gente.

Foi aí que entrei em contato com ele por e-mail e perguntei como isso tinha acontecido. Ele me explicou que já estava há algum tempo participando de processos no exterior através de uma empresa de recrutamento chamada honeypot.io (que foi incorporada pela Xing – um tipo de LinkedIn).

Como eu não tinha mais emprego, era uma boa hora de mandar meu currículo para qualquer lugar do mundo e tentar morar fora novamente, depois de uma experiência em San Francisco, CA.

Pois bem, depois de muitos processos, consegui três ofertas oficiais: uma dos EUA (remoto, morando no Brasil), uma em BH e outra para me mudar para a Alemanha. Você já entendeu qual escolhemos, né? Todo o processo de mudança demorou 6 meses e envolveu muita burocracia, mas isso não é papo para agora.

O choque cultural foi imenso. Era minha primeira vez na Alemanha, aliás, minha primeira vez em solo europeu. E agora consigo listar 5 pontos sobre o que mais mudou em mim.

Desigualdade como o motor dos problemas sociais:

A Alemanha me mostrou como a desigualdade social é um dos principais fatores por trás de problemas como criminalidade(e segurança pública no geral). Aqui, a distribuição de renda e o acesso a serviços básicos são mais equilibrados, o que resulta em uma sociedade mais segura e estável. Isso me fez refletir sobre como políticas públicas podem impactar diretamente a qualidade de vida das pessoas.

Cultura é construção:

Aprendi que a cultura não é algo fixo, mas sim algo que se constrói e se transforma. É comun ver homens(principalmente árabes), demonstrando afeto entre si, algo que no Brasil ainda é visto com certos preconceitos. Isso me mostrou como os valores sociais podem ser diferentes e como é importante respeitar e entender essas diferenças. Ah, e o alemão faz xixi sentado, outro ponto que na nossa cultura não é comum.

Não existe lugar perfeito:

A vida na Europa não é um mar de rosas. Apesar das muitas vantagens, também existe muito racismo, xenofobia e preconceitos(nunca sofremos,mas existe) em geral. Isso me fez perceber que quando você muda, você só troca de problemas. Nenhum lugar é perfeito.

Menos consumismo, mais foco em experiências:

Aqui, percebi que as pessoas valorizam menos o ter e mais o viver. O consumismo desenfreado que vemos no Brasil dá lugar a um estilo de vida mais simples e focado em experiências, como viagens, passeios e momentos em família. Isso mudou minha perspectiva sobre o que realmente importa na vida.

Valorizar mais o Brasil:

Morar fora me fez valorizar ainda mais o Brasil, especialmente o clima e o sol. A Alemanha tem invernos longos e escuros, e isso me fez sentir falta do calor e da luz do Brasil. Além disso, passei a admirar mais a cultura brasileira, nossa diversidade e nossa capacidade de superar desafios. Quando chega um Brasileiro aqui falando mal do Brasil eu já corto e tento mostrar o lado bom.

--
Pra finalizar, acho que todo mundo que tiver condição, deveria morar fora(seja do país ou apenas de seu estado). Conhecer novas culturas expande sua cabeça para outros estilos de vida, te ajuda a ser mais empático e acolhedor. Nada mata melhor o preconceito do que conviver com o diferente.

My First Side Project Was a Success—and Then I Blew It

Diogo Viana — Tue, 10 Dec 2024 00:44:55 +0000

The year was 2005, and I was in my second year of Computer Science. I loved web development and wanted to learn a language that could help me build real applications.

At the time, tabletop RPG players—myself included—had a problem. Games like Vampire: The Masquerade required groups to meet in person, but as we grew older, got jobs, and scattered across cities, gathering became impossible. There were no online tools to play RPGs with friends.

So I decided to build one.

The Birth of a (Very Messy) Solution

I bought a PHP book and dove in. But I quickly realized: Programming isn't learned by reading alone—you have to build. So I set out to create a platform where game masters could form groups, manage players, and run sessions with a chat and dice-rolling system.

This was 2005:

No YouTube tutorials(actually, no Youtube at all)
No Stack Overflow
Just Orkut forums
A dog-eared PHP manual

Somehow, I made it work. The code was spaghetti, the frontend used HTML tables for layout (CSS was a mystery), and deployment meant FTP-ing files via FileZilla. But it worked.

The Rise and Fall of My RPG Empire

I announced the tool on Orkut's RPG communities. Players went wild:

1,000 users in two weeks
7,000 visitors that month

I was euphoric, dreaming of new features.

Then reality hit:

No version control (GitHub didn't exist)
My "deployment strategy": Take site offline to code updates
Sent the fateful email: "We'll be back with upgrades!"

I was so naive that I thought "I have to take the web app down while I write new features, and then when it's finished, I'll put it back up." - I didn't know version control, remember?

Between my day job and inexperience, I never wrote those features. Years passed. I kept paying for the domain... until 2015, when I finally let go.

What did I learn from that?

The most important: Programming is about practice. You're only going to get good at it if you practice. Learn the theory, but practice more. Write code. Read code. Try. Fail. Practice every day.

Do not let yourself down if things don't work out as you expected. Just build. Eventually, you'll get it right and learn a ton along the way.

PS.

Two decades later, I'm finally building again. Not for glory, but for the joy of creating—and this time they made it to production.

Frame6 - A game quiz about movies. You can play alone or with your friends.
Passshare - A web application for sharing passwords in a secure way.

Docker Compose with Rails 8, Tailwind and SQLite

Diogo Viana — Mon, 18 Nov 2024 22:03:11 +0000

Hello, long time no see!

In this guide I'm going to show you how to use Docker Compose to setup and run a Ruby On Rails application using the brand new version 8. In this guide I'm not going to list all new features that are shipped with the newest version. If you want to know more about, you can check the official release note.

There's only one requirement to make this guide work, which is having Docker or OrbStack installed on your computer. That's it. You don't need to install Ruby, Postgres, SQLite, Redis... nothing.

This is an updated version of a quickstart guide I wrote a while back.

Setup folder

First, let's create a directory for your project and then create 5 empty files inside of it.

mkdir my-project
cd my-project
touch Dockerfile.dev
touch docker-compose.yml
touch Gemfile
touch Gemfile.lock
touch .ruby-version

Define the project

Start by setting up the files needed to build the app. The app will run inside a Docker container containing its dependencies. Defining dependencies is done using a file called Dockerfile.dev. Let's add the following inside of it::

# syntax = docker/dockerfile:1

# Make sure RUBY_VERSION matches the Ruby version in .ruby-version and Gemfile
ARG RUBY_VERSION=3.4.2
FROM registry.docker.com/library/ruby:$RUBY_VERSION-slim-bookworm

# Rails app lives here
WORKDIR /rails

# Install packages needed to build gems
RUN apt-get update -qq && \
  apt-get install --no-install-recommends -y build-essential git libpq-dev libvips pkg-config node-gyp curl sqlite3 nano libyaml-dev

ARG NODE_VERSION=20.15.0
ARG YARN_VERSION=latest
ENV PATH=/usr/local/node/bin:$PATH
RUN curl -sL https://github.com/nodenv/node-build/archive/master.tar.gz | tar xz -C /tmp/ && \
  /tmp/node-build-master/bin/node-build "${NODE_VERSION}" /usr/local/node && \
  npm install -g yarn@$YARN_VERSION && \
  rm -rf /tmp/node-build-master

# Run bundle install
COPY Gemfile Gemfile.lock ./
COPY .ruby-version ./
RUN bundle install

# Copy application code
COPY . .

# Entrypoint prepares the database.
ENTRYPOINT ["/rails/bin/docker-entrypoint"]

# Start the server by default, this can be overwritten at runtime
EXPOSE 3000
CMD ["rails", "server", "-b", "0.0.0.0"]

Tip

It is important to use the .dev as extension for this file otherwise rails new command will replace it.

That'll put your application code inside an image that builds a container
with Ruby, Bundler and all your dependencies inside it. For more information on
how to write Dockerfiles, see the Docker user guide
and the Dockerfile reference.

Next, open an editor and create a bootstrap Gemfile which just loads Rails. This will be overwritten in a moment by rails new. At this point you can use whatever rails version you want.

source 'https://rubygems.org'
gem 'rails', '~> 8.0'

To have all files using the same version, let's add this to the .ruby-version file.

ruby-3.4.2

Finally, docker-compose.yml is where the magic happens. This file describes the services that comprise your app and the configuration needed to make the app run.

services:
  web:
    build:
      context: .
      dockerfile: Dockerfile.dev
    command: bash -c "./bin/dev"
    tty: true
    volumes:
      - .:/rails
    ports:
      - "3000:3000"

Tip

You have to use tty:true so we can watch for changes on css/js files.

Build the project

With those files in place, you can now generate the Rails skeleton app using docker compose run:

$ docker compose run --no-deps web rails new . --name=my-project  --force --css=tailwind --js=esbuild

When you run this command, Compose builds the image for the web service using the Dockerfile.dev file.
The --no-deps tells Compose not to start linked services. Then it runs rails new inside a new container, using that image.

Once it's done, you should have generated a fresh app inside of your folder.

Tip

If you are running Docker on Linux, the files rails new created are owned by root, you might have to run chown to change that.
$ sudo chown -R $USER:$USER .

Now that you’ve got a new Gemfile, you need to build the image again. (This, and changes to the Gemfile or the Dockerfile, should be the only times you’ll need to rebuild.)

$ docker compose build

Running the project

Before you boot your app, let's make sure we bind 0.0.0.0 to our server. Go to Procfile.dev and add '-b 0.0.0.0' at the end of the first line, it should look like this.

web: env RUBY_DEBUG_OPEN=true bin/rails server -b 0.0.0.0
js: yarn build --watch
css: yarn build:css --watch

And the last step before you spin your project app, let's do some minor modifications on the Dockerfile.dev file. Add these lines right after

COPY ..

# Entrypoint prepares the database.
ENTRYPOINT ["/rails/bin/docker-entrypoint"]

The final Dockerfile.dev should looke like this:

# syntax = docker/dockerfile:1

# Make sure RUBY_VERSION matches the Ruby version in .ruby-version and Gemfile
ARG RUBY_VERSION=3.4.2
FROM registry.docker.com/library/ruby:$RUBY_VERSION-slim-bookworm

# Rails app lives here
WORKDIR /rails

# Install packages needed to build gems
RUN apt-get update -qq && \
  apt-get install --no-install-recommends -y build-essential git libpq-dev libvips pkg-config node-gyp curl sqlite3 nano libyaml-dev

ARG NODE_VERSION=20.15.0
ARG YARN_VERSION=latest
ENV PATH=/usr/local/node/bin:$PATH
RUN curl -sL https://github.com/nodenv/node-build/archive/master.tar.gz | tar xz -C /tmp/ && \
  /tmp/node-build-master/bin/node-build "${NODE_VERSION}" /usr/local/node && \
  npm install -g yarn@$YARN_VERSION && \
  rm -rf /tmp/node-build-master

# Run bundle install
COPY Gemfile Gemfile.lock ./
COPY .ruby-version ./
RUN bundle install

# Copy application code
COPY . .

# Entrypoint prepares the database.
ENTRYPOINT ["/rails/bin/docker-entrypoint"]

# Start the server by default, this can be overwritten at runtime
EXPOSE 3000
CMD ["rails", "server", "-b", "0.0.0.0"]

Now run

docker compose build

again and then finaly,

docker compose up

.

View the Rails welcome page!

That's it. Your app should now be running on port 3000 on your Docker daemon, go to http://localhost:3000 on a web browser to see the Rails Welcome.

Stop the application

To stop the application, run docker compose down in your project directory. You can use the same terminal window in which you started the database, or another one where you have access to a command prompt. This is a clean way to stop the application.

docker compose down
 ✔ Container my-project-web-1  Removed0.0s
 ✔ Network my-project_default  Removed

Restart the application

To restart the application run docker compose up in the project directory.

Rebuild the application

If you make changes to the Gemfile or the Compose file to try out some different
configurations, you need to rebuild. Some changes require only
docker compose up --build, but a full rebuild requires a re-run of
docker compose run web bundle install to sync changes in the Gemfile.lock to
the host, followed by docker compose up --build.

Here is an example of the first case, where a full rebuild is not necessary.
Suppose you simply want to change the exposed port on the local host from 3000
in our first example to 3001. Make the change to the Compose file to expose
port 3000 on the container through a new port, 3001, on the host, and save
the changes:

ports:
  - "3001:3000"

Now, rebuild and restart the app with docker compose up --build.

Inside the container, your app is running on the same port as before 3000, but
the Rails Welcome is now available on http://localhost:3001 on your local
host.

Good alternatives to Heroku

Diogo Viana — Sun, 26 May 2024 00:23:29 +0000

A while ago, I attempted to deploy a side project on Heroku, and, to my surprise, a lot had changed on the platform. Basically, Heroku's free-tier service was no longer available. This was not only bad news for me, but also for every Rails developer who had side projects running there.

So, I went to Twitter to express my concerns about these changes and received many replies suggesting good alternatives. As a result, I have compiled all these suggestions here for you and for my future reference

Here's the list:

Digital Ocean -
Good prices, documentation and they have something similar to Heroku with App Platform. Good for small and big projects.
Hetzner -
Very similar to Digital Ocean, you can create VPS, databases, load balancers and more. Good prices and it can handle both big and small projects.
Vercel -
Never used but and it seems very specific for Frontend developers.
Fly.io -
Very similar to Heroku too, easy to use and support for multiple stacks/languages.
Pocketbase -
Never used before but it says in their home page the following: "Open Source backend for your next SaaS and Mobile app in 1 file". Seems porwerful.
Planetscale -
Directly from their website: "PlanetScale is a MySQL-compatible serverless database that brings you scale, performance, and reliability — without sacrificing developer experience."
Render -
I think render is more like a cloud agnostic builder/runner platform, this means that your application needs to be hosted somewhere else.
Railway -
Language agnostic and for projects big and small. Never used but it seems very easy to use like Heroku.
Subpabase -
Like Planetscale this is only for databases. It is an open source Firebase alternative for building secure and performant Postgres backends with minimal configuration.
Oracle Cloud -
Oracle Cloud offers a free-tier for a year.
AWS Amplify -
Very easy to use, connects to your github repository and can also create review apps based on branches.
Cyclic -
"Connect your GitHub repo. We will build, deploy and manage the hosting."

And last but not least, Netlify, which is the one I use to host this website(for free). Hugo + Netlify is a powerful combination.

If you have any suggestions that I might have missed, feel free to post in the comments.

Forem: Diogo Viana

Quick Rails Tip: Change Database Adapter

The magic command

What does this command do

More practical examples

Important considerations

Conclusion

Por que seus pull requests devem ser pequenos

Motivação

Quais os reais benefícios percebidos?

1. Revisões Mais Rápidas e Eficientes

2. Maior Qualidade nas Revisões

3. Menor Probabilidade de Bugs

4. Código modular

Como escrever PRs pequenos

Quando PRs grandes são aceitáveis?

Conclusão

P.S

Setup Rails Active Storage with Hetzner

Introduction

Prerequisites

Table of Contents

Creating a Bucket

Generating Credentials

Configuring Your Rails Application

Testing Your Configuration

Security Considerations

Conclusion

8 Anos de Alemanha e como isso me mudou

Desigualdade como o motor dos problemas sociais:

Cultura é construção:

Não existe lugar perfeito:

Menos consumismo, mais foco em experiências:

Valorizar mais o Brasil:

My First Side Project Was a Success—and Then I Blew It

The Birth of a (Very Messy) Solution

The Rise and Fall of My RPG Empire

What did I learn from that?

PS.

Docker Compose with Rails 8, Tailwind and SQLite

Setup folder

Define the project

Build the project

Running the project

View the Rails welcome page!

Stop the application

Restart the application

Rebuild the application

Good alternatives to Heroku

Here's the list: