Then I hit the cp command issues, which I found in an older Kamal repository issue. There's a difference in the macOS and the Linux flavor of these utilities. To get around this error, we install coreutils with homebrew. (I understand there are some intricacies in the gnutools, however, this is purely a sandbox.) And then update the ~/.zshenv with another line export PATH=/opt/homebrew/opt/coreutils/libexec/gnubin:$PATH

After overcoming these two small issues, I was able to successfully deploy (a relatively simple app) in about 10 seconds.

As far as the Kamal goes, I'm using an accessory service that runs litestream's provided docker container (https://hub.docker.com/r/litestream/litestream).

You'll want to be sure to add a config/litestream.yml file in your Rails application with this contents, the keys are interpolated by Litestream later so we need to ensure they're included in our secrets (https://litestream.io/reference/config/#auto-read-environment-variables):

dbs:
  - path: /data/production.sqlite3
    replica:
      type: s3
      path: db # this is the path in your bucket
      bucket: your-bucket
      region: your-region
      access-key-id: ${AWS_ACCESS_KEY_ID}
      secret-access-key: ${AWS_SECRET_ACCESS_KEY}

Once we have this setup we can move on to the config/deploy.yml for Kamal:

volumes:
  - "storage:/rails/storage"
  # - /host:/path/on/container
  
accessories:
  litestream:
    host: host-ip
    image: litestream/litestream
    env:
      secret:
        - LITESTREAM_ACCESS_KEY_ID
        - LITESTREAM_SECRET_ACCESS_KEY
    cmd: "replicate"
    files:
      - config/litestream.yml:/etc/litestream.yml
    volumes:
      - "storage:/data"

I've included the overall application volume setup in the Kamal file as this is important. The accessory needs to know this exists and maps the volume to the data folder for the Litestream image container.

Once you have these committed and run kamal accessory reboot litestream you should be able to tail the Litestream container and see the connection and replication happen to your S3 instance.

time=2025-12-31T00:00:00.380Z level=INFO msg="snapshot complete" txid=000000000000001e size=1170108
time=2025-12-31T03:15:00.226Z level=INFO msg="compaction complete" level=1 txid.min=000000000000001f txid.max=0000000000000020 size=368
time=2025-12-31T03:15:00.299Z level=INFO msg="compaction complete" level=2 txid.min=000000000000001f txid.max=0000000000000020 size=368
time=2025-12-31T04:00:00.215Z level=INFO msg="compaction complete" level=3 txid.min=000000000000001f txid.max=0000000000000020 size=368
time=2025-12-31T04:38:30.231Z level=INFO msg="compaction complete" level=1 txid.min=0000000000000021 txid.max=0000000000000022 size=1121

Both of the Docker projects we'll be taking advantage of have a similar approach to running on a schedule to create a backup. Taking it a bit further with Docker volumes and networks allows us to have an easier restoration in the case of database loss.

Example 1: Local Backups

In the first example, we'll utilize a docker image (postgres-backup-local) that will backup based on your schedule and keep the backups local to your network share. When we're working with keeping files and data around in Docker its important we work with volumes. If you're connecting to a file share locally a good starting point is the Docker documentation on volume drivers.

Note: you may need to install nfs-common on your virtual machine, if you're using Linux.

Once you've figured out where you need to connect, and you have the proper credentials and networking path aligned, you can create a new Docker volume similar below. This example is creating an NFS Docker volume with the name volume-name.

$ docker volume create --driver local --opt type=nfs --opt o=addr=IP-ADDRESS,rw --opt device=:/fileshare/path volume-name

In your Kamal deploy.yml configuration file you'll want to add a section under the accessories key, with your desired name. I've configured this accessory as db-backups.

accessories:
  db-backups:
    image: prodrigestivill/postgres-backup-local
    roles:
      - web
    env:
      clear:
        SCHEDULE: '@daily'
        POSTGRES_USER: postgres
        BACKUP_KEEP_DAYS: 7
        BACKUP_KEEP_WEEKS: 4
        BACKUP_KEEP_MONTHS: 6
        POSTGRES_DB: my-db
        POSTGRES_HOST: local-ip
      secret:
        - POSTGRES_PASSWORD
    volumes:
      - volume-name:/backups
    options:
      "user": "postgres:postgres"

Hint: Some items to point out in the config code above. We're setting our volume to be mounted at the path /backups internal to the container running our accessory. Your POSTGRES_USER should be set to whatever your database user is for the current environment you're backing up.

You'll need to push your new configured environment variables to the server.

$ kamal env push

Boot the db-backups accessory. The result of this will be a container you can terminal into that runs on the schedule defined in your ENV variables.

$ kamal accessory boot db-backups

You should immediately see a file in the /backups/last directory which would be the last run of the backup.sh (found on the container). Keep in mind that /backups is the volume linked to your network share. If you don't see a Postgres backup file, double check that you can successfully connect to the accessory container and run bash backup.sh manually.

Restore database from backup

To restore the database simply login to the accessory that contains the link to the backups. (docker ps to find the container ID)

$ docker exec --tty --interactive $CONTAINER_ID /bin/sh -c "zcat /backups/last/$MY_DB-latest.sql.gz | psql --username=postgres --dbname=$MY_DB -W"

You can also mount the volume we created earlier for backups on your postgres database accessory. Then you can run the restore command above from your postgres container.

Example 2: Cloud Backups

In the second example, we'll utilize an object storage volume and the docker image (eeshugerman/postgres-backup-s3) to take backups on a schedule and push them to S3. This project has some nice features, so be sure to checkout the linked Github repository.

In your deploy.yml configuration file we'll want to create a new key that describes our s3 Postgres backup.

accessories:
  s3-pgbackup:
    image: eeshugerman/postgres-backup-s3:15
    roles:
      - web
    env:
      clear:
        SCHEDULE: '@midnight'
        BACKUP_KEEP_DAYS: 14
      secret:
        - S3_REGION
        - S3_ACCESS_KEY_ID
        - S3_SECRET_ACCESS_KEY
        - S3_BUCKET
        - S3_PREFIX
        - POSTGRES_HOST
        - POSTGRES_DATABASE
        - POSTGRES_USER
        - POSTGRES_PASSWORD

You'll need to have set secret environment variables for S3 and Postgres and push those via Kamal:

$ kamal env push

In the deploy.yml example above, you can see I have the image tagged to version 15 of Postgres, you can use any version 12-16. We're explicitly telling this accessory that it will operate on our web server and sending the schedule and some rules along with it. Check the documentation for how the SCHEDULE variable works.

Boot the accessory.

$ kamal accessory boot s3-pgbackup

I have not had the chance to dive into adding a block storage device to docker, yet. I'm sure it's possible so the restore can act similarly to the first example for restoring. (I'll revisit and update the post if I do.)

Set a reminder to double check that the container is running backups on schedule at your S3 location.

That's all for now!

This article is meant as a reminder for myself, but, figured it may help someone out on the internet. I recently updated an old project where I utilized SQLite in production and configured it for deployment with Kamal.

This posed a few different problems that anyone with this setup will need to solve for:

• Persisting the SQLite file on the host machine, this would allow us to be able to restart the container, destroy the container, rebuild the container and still have our data.
• Connecting ActiveStorage to a long-lived file system to again, persist any container restarts, rebuilds, etc.

Firstly, we need to SSH into our target VM on whatever VPS provider you prefer. We'll create two directories at the top level of the file system. (You can place them wherever you'd like.) I put them here for easy access later.

$ mkdir /db

$ mkdir /storage

Then we'll need to change the permissions of these directories so our user within our container can access them. You can read more about volumes, docker, and permissions in containers here. I've done this with changing the ownership of the directories to the user with ID 1000, as that's our rails user in our container for the application. You may also need to modify the permissions on the storage folder to: sudo chmod -R 775 /storage

$ chown 1000:1000 /db /storage

A simplified Kamal deploy file should look as follows:

# Name of your application. Used to uniquely configure containers.
service: web-app

# Name of the container image.
image: my-image

# Deploy to these servers.
servers:
  web:
    hosts:
      - MY_HOST_IP

volumes:
  # host path:container path
  - "/db:/rails/sqlite"
  - "/storage:/rails/storage"

# Credentials for your image host.
registry:
  # Specify the registry server, if you're not using Docker Hub
  # server: registry.digitalocean.com / ghcr.io / ...
  username: kamal

  # Always use an access token rather than real password when possible.
  password:
    - KAMAL_REGISTRY_PASSWORD

# Inject ENV variables into containers (secrets come from .env).
# Remember to run `kamal env push` after making changes!
env:
  secret:
    - RAILS_MASTER_KEY


# Configure builder setup.
builder:
  secrets:
    - RAILS_MASTER_KEY

The main thing to point out here is we're using volumes over Kamal's concept of files or directories. This means you could put your stage database and your production database in the same folder and mount the container in either environment on the same server if you wanted.

For data persistence and recovery you'd want to setup a way to offload your /db and /storage directories.

The configuration for Active Storage is simple, check your environment file is pointing config.active_storage.server = :local and be sure you have an entry in your storage.yml file similar to:

local:
  service: Disk
  root: <%= Rails.root.join("storage") %>

That's it, kamal deploy to your hearts content.

I've used Gitlab and BitBucket Pipelines to successfully configure this in the recent past. Your mileage may vary with Github, as I haven't had a need to deploy with it yet. I've linked a post below that might help you deploy with Kamal and Github Actions. As with most solutions, this is a simple example to get you deployed. Your environment, development process and application conditions will vary.

Configure SSH Keys

Once you have a repository for your code, you'll need to configure the SSH keys to allow the CI/CD workers access to your server. BitBucket makes this relatively easy, they create an SSH key for you as well as allow you to add a known_hosts entry. Go to Respository Settings > SSH Keys from your repository. Follow the instructions on screen. You'll add the generated public key to the authorized_keys on your server (staging/production).

Configure Environment Variables

Next you'll want to enter in your environment variables for the specific stage of deployment. If you go to Repository Settings > Deployments you'll see three default environments. Enter the variables so they match up with what you're needing for Kamal to run. For instance, I setup these variables in various forms of clear text and secret values:

RAILS_MASTER_KEY=
POSTGRES_PASSWORD=
REDIS_URL=
DB_HOST=
RAILS_ENV=

The above key value pairs will be used when Kamal generates the env files for your application containers. On the BitBucket side $RAILS_MASTER_KEY will evaluate to that value when the Pipeline runs. If the value was entered as a secret, the value will be masked in the logs with the key name. This usually happens when running the envify command of Kamal, alternatively you can also use the Kamal env command to manage the env files and push them up to your virtual machine.

Create or update bitbucket-pipeline.yml

Time to configure the Pipeline yaml file. As it always seems to go, each vendor has their own flavor of CI/CD configuration. There are differences to each platform, and one may not fit your needs. Below I've entered a simple Pipeline which is manually triggered on our repository. When we push to the main branch the Pipeline will run and wait for us to confirm the deploy. This is where your development process will come in and you can slot this deploy anywhere based on your own Pipeline rules.

From top to bottom, we're starting off by having the overall Pipeline use the Ruby image. We need docker included to run our Kamal commands and this is specific to BitBucket on how they allow docker in their Pipelines. After that we create a cache for bundler. (This may be unnecessary.)

Within the pipelines key in the yaml, you'll see our named Deploy to Staging step. We reference the cache, set the deployment type and trigger to manual. The script portion of this is where all the action happens. We'll need to tell BitBucket to enable docker buildkit. After that, since the Kamal gem has dependencies that require a few system level packages, you'll see we add apt-get install -y ca-certificates curl gnupg openssh-client build-essential git to ensure we have everything we need to gem install kamal.

# bitbucket-pipeline.yml

image: ruby:3.2.2-slim

options:
  docker: true

definitions:
  caches:
    bundler-cache:
      key:
        files:
          - Gemfile.lock
      path: vendor/bundle

pipelines:
  default:
    - step:
        name: 'Deployment to Staging'
        caches:
          - bundler-cache
        deployment: staging
        trigger: 'manual'
        script:
          - export DOCKER_BUILDKIT=1
          - apt-get update && apt-get install -y ca-certificates curl gnupg openssh-client build-essential git
          - gem install kamal
          - kamal envify -d staging
          - kamal deploy -d staging

Let the Kamal fun begin. We'll focus in on the second to last line kamal envify -d staging. When we run envify, Kamal will lookup the variable values we set for the deployment on BitBucket since that's the context we're in. It will generate the .env or .env.staging in this case, based on your .env.*.erb. Be sure to have that file included in your project. Then envify will run based on dotenv gem hierarchy and priority (https://github.com/bkeepers/dotenv#what-other-env-files-can-i-use). You'll see SSH connections happening and uploading to your virtual machine. You can login to your server and verify the env values are set and coming in as expected, just check the .kamal folder on the server. You can even modify this file to fix a failing container from starting, if you had to. Just know that it could change after any envify or env push command.

After that, the running of the Kamal deploy command will go thru the normal build process, push to your repository, and do the reverse, pull latest and deploy dance. After a successful deploy you'll have the new version of your application released available on your virtual machine.

Some parting notes for debugging

If you see a failure happen, check the commands that Kamal is running. You can likely reproduce exactly where the failure is happening and back track to what the issue is. More than likely it will land in the env variable being the culprit, or a value not being present that is expected at application load time.

You can login to your server and run the images that are stored on your server. docker exec -it CONTAINER_ID /bin/bash is a helpful one to get in and poke around with what Kamal is trying to run. printenv will output environment variables in the container. If the container isn't running use docker run -it CONTAINER_ID /bin/bash. You can also output logs of running containers with the docker logs CONTAINER_ID command.

How To Use Basecamp’s Kamal With AWS and GitHub

Learn how to use Basecamp’s Kamal to deploy Rails application to AWS with GitHub Actions

JetRocketsIgor Alexandrov

I understand that many developers may not carry-over to the dark side of DevOps things. Comprehending all that Kamal is can be a daunting task. You should have some knowledge of Traefik and Docker.

In this example, we'll have 2 Rails Applications, luckily Rails 7.1.0.beta1 was recently released with all the new goodness. Both Applications in this example are the exact same, SQLite3, esbuild, vanilla out of the box configuration. I'm using Kamal version 1.0.0. The end goal of each was a green response at the route /up.

Want to run your own Docker registry instance for Kamal? Check out my post about it.

Here's a bit of a visual of how things are setup on the single instance:

Kamal commands our server instance through the deploy.yml file we create. If this instance is located on the cloud, you'll have the SSH key to login local to your machine, Kamal simply uses that to login as root and run commands for you.

Kamals kamal server command will bootstrap the server with what is necessary, and at the base of it all is: docker and curl, the Traefik container being the reverse proxy we need to route the traffic in to each container.

This setup is a bit odd in that the first project you'll run the kamal init command in will have some of the traefik configuration we need in it for SSL. If you're hosting a bunch of small projects and don't care if there is overlap into another project then you can continue.

After you've setup the server instance with docker you can login to it and create a directory /letsencrypt/acme.json and file with the contents {}, you can then chmod it 600.

Site 1 Configuration

# deploy.yml

service: site1

image: my-registry/site1

# Deploy to these servers.
servers:
  web:
    hosts:
      - yourip
    options:
      "add-host": host.docker.internal:host-gateway
    labels:
      traefik.http.routers.rails_recipes.entrypoints: websecure
      traefik.http.routers.rails_recipes.rule: Host(`rails.recipes`)
      traefik.http.routers.rails_recipes.tls.certresolver: letsencrypt

# Credentials for your image host.
registry:
  # Specify the registry server, if you're not using Docker Hub
  server: registry.digitalocean.com
  username: deploy

  # Always use an access token rather than real password when possible.
  password:
    - KAMAL_REGISTRY_PASSWORD

traefik:
  options:
    publish:
      - "443:443"
    volume:
      - "/letsencrypt/acme.json:/letsencrypt/acme.json"
  args:
    entryPoints.web.address: ":80"
    entryPoints.websecure.address: ":443"
    entryPoints.web.http.redirections.entryPoint.to: websecure
    entryPoints.web.http.redirections.entryPoint.scheme: https
    entryPoints.web.http.redirections.entrypoint.permanent: true
    certificatesResolvers.letsencrypt.acme.email: "you@youremail"
    certificatesResolvers.letsencrypt.acme.storage: "/letsencrypt/acme.json"
    certificatesResolvers.letsencrypt.acme.httpchallenge: true
    certificatesResolvers.letsencrypt.acme.httpchallenge.entrypoint: web

After you have this in your deploy.yml, save it. Be sure your env variables are up to date with kamal env push. You'll notice the naming conventions Kamal uses for your services. This helps in the flexibility of being able to deploy multiple applications.

Run kamal deploy to push this application up to the server.

If you haven't configured traefik yet, you'll what to likely run kamal traefik restart or kamal traefik reboot if its not picking up your changes. Give LetsEncrypt a little time to catch up with the certificate.

Site 2 Configuration

# deploy.yml

service: site2

image: my-registry/site2

servers:
  web:
    hosts:
      - yourip
    options:
      "add-host": host.docker.internal:host-gateway
    labels:
      traefik.http.routers.site2-web.entrypoints: websecure
      traefik.http.routers.site2-web.rule: Host(`changelog.lol`)
      traefik.http.routers.site2-web.tls.certresolver: letsencrypt

registry:
  # Specify the registry server, if you're not using Docker Hub
  server: registry.digitalocean.com
  username: deploy

  # Always use an access token rather than real password when possible.
  password:
    - KAMAL_REGISTRY_PASSWORD

The same goes for this site, be sure you have your env variables up to date and push them. They'll end up in .kamal/env/roles directory on your server instance. You can SSH and check them out there, too.

Now all you need to do is run the kamal deploy command from your other application directory and Kamal will deploy this app for you and start the container. Since we already have Traefik running it will get notified of the changes via the labels we're pushing. You can also watch this with the docker logs command from the server.

I hope this helps you with general concepts or debugging getting your application deployed.

This is dedicated to someone who kept asking me how to do this.

Well, you've made it this far. If you happen to be a developer, check out my in-app feedback tool that I'm hacking on.

We'll utilize docker compose for this setup, as well as Traefik to proxy our requests, provide SSL over LetsEncrypt and whitelist our internal IPs.

First you'll want to spin up a virtual machine instance, droplet, EC2, whatever you prefer. For this service it shouldn't need much, I've given it a 1gb and 1vCPU instance.

Be sure you have the latest version of docker installed on this instance.

Configuring Traefik

We'll begin by configuring Traefik. Create a docker-compose.yml file. You'll likely need to create a network in docker as well (simply run docker network create traefik)

version: '3'

services:
  traefik:
    image: traefik
    ports:
    - "80:80"
    - "443:443"
    command:
     - "--log.level=INFO"
     - "--providers.docker=true"
     - "--providers.docker.exposedbydefault=false"
     - "--entrypoints.web.address=:80"
     - "--entrypoints.websecure.address=:443"
     - "--certificatesresolvers.le.acme.httpchallenge=true"
     - "--certificatesresolvers.le.acme.httpchallenge.entrypoint=web"
     - "--certificatesresolvers.le.acme.caserver=https://acme-v02.api.letsencrypt.org/directory"
     - "--certificatesresolvers.le.acme.email=you@yourdomain.com"
     - "--certificatesresolvers.le.acme.storage=acme.json"
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock
    - ./acme.json:/acme.json
    networks:
     - traefik
 
networks:
  traefik:
    external: true

From top to bottom, what this file is doing is passing command line configuration options to the traefik container. Setting the log level, telling Traefik there is a provider at the docker socket but to not expose any of our other services unless we tell it to. Further on, we're leaving our instance ports of 80 and 443 open to actively accessible from anywhere. These are known as entry points in Traefik and we can define routes and additional services as you'll see later. After that we get into setting up the LetsEncrypt certificate resolvers. This is using the most basic challenge, you can view the Traefik documentation for other scenarios.

The volumes section is identifying the docker socket that Traefik should know about. The acme.json file is a file you'll need to create within the directory you have your docker-compose.yml file. You may need to change its contents to include {} if an empty string causes issue.

If you were able to follow along this far, congratulations, you have a server that can accept connections on 80 and 443. To get that hooked up to your domain, you'll need to change your domains DNS to point to this instance. You should probably do that now.

Docker Registry Setup

Let's get the Docker registry container setup.

Add an extra service entry in your docker-compose.yml file. We'll go ahead and go over each of the configuration options below. If you are okay hosting the repository images on this instance, you can just configure the data directory environment REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data and point it to a local volume /data and be on your way, however I'm going to setup S3 to be the storage provider for this example.

registry:
    restart: always
    image: registry:latest
    environment:
      REGISTRY_AUTH: htpasswd
      REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
      REGISTRY_AUTH_HTPASSWD_PATH: /auth/registry.password
      REGISTRY_STORAGE: s3
      REGISTRY_STORAGE_S3_ACCESSKEY: accesskey
      REGISTRY_STORAGE_S3_SECRETKEY: secretkey
      REGISTRY_STORAGE_S3_BUCKET: bucket-name
      REGISTRY_STORAGE_S3_REGION: region-1
      REGISTRY_HEALTH_STORAGEDRIVER_ENABLED: false
    volumes:
      - ./auth:/auth
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.registry.rule=Host(`yourdomain.com`)"
      - "traefik.http.routers.registry.tls=true"
      - "traefik.http.routers.registry.tls.certresolver=le"
      - "traefik.http.routers.registry.entrypoints=websecure"
      # You can remove the line below to make accessible publicly
      - "traefik.http.middlewares.private-network.ipwhitelist.sourcerange=comma,delimited,ips,here,to,allow"
      - "traefik.http.routers.registry.middlewares=private-network@docker"
      - "traefik.http.services.registry.loadbalancer.server.port=5000"
    networks:
     - traefik

First we need to install and set the htpasswd on our instance. Install apache2-utils, this includes what we need to generate our authorization information. Run sudo apt install apache2-utils.

Generate your login with htpasswd -Bc registry.password your_user. You can pass in the your user as however you'd like to identify the login. After that, this command will prompt you to enter a password that you'd like to use. The hash is stored in the registry.password file. You can verify your password set correctly with the htpasswd -v registry.password your_user command, which will prompt you to enter the password and return whether correct or not.

As you can see, we're setting up some environment variables. Be sure your pathing matches up. You may need to create a directory for the auth and push the file you just created.

S3 Setup

Do the Amazon S3 bucket configuration dance. And once you're done, bring back those required environment variable values with you and plug them into your docker-compose.yml.

When you're in configuring the IAMS user or group, here's a policy that might help you. I had a bit of an issue on understanding what was required and it seems the S3 storage component needed a special listing ability. The documentation example file is inaccessible or missing on the official Docker Registry repo.

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": [
				"s3:ListAllMyBuckets"
			],
			"Resource": "arn:aws:s3:::*"
		},
		{
			"Effect": "Allow",
			"Action": [
				"s3:ListBucket",
				"s3:GetBucketLocation",
				"s3:ListBucketMultipartUploads"
			],
			"Resource": "arn:aws:s3:::your-bucket"
		},
		{
			"Effect": "Allow",
			"Action": [
				"s3:PutObject",
				"s3:GetObject",
				"s3:DeleteObject",
				"s3:ListMultipartUploadParts",
				"s3:AbortMultipartUpload"
			],
			"Resource": "arn:aws:s3:::your-bucket/*"
		}
	]
}

We're coming into our final explanation of the remaining lines of the docker-compose.yml file. The labels under the registry service from top to bottom are telling traefik to be aware of this container. The remaining lines are setting up routers based on your domain and the LetsEncrypt certificate resolver we setup earlier. The middle wares can be configured to only allow your internal cloud network resources to access your registry as an extra security precaution. You can comment or remove that line altogether. Lastly, we tell traefik we're running our service on port 5000. By default, docker registry runs there.

Final Thoughts

You should be up and running with a docker compose up -d command. You can attempt to login to your registry from another server or your own terminal with docker login registry.yourdomain.com.

You can view the full gist here.

Below we'll install the needed Ruby gems and JavaScript packages necessary to get you designing out a simple static site with Bridgetown and TailwindCSS.

Step 1: Install the gems

$ gem install bundler bridgetown -N

Step 2: Create a project with Bridgetown

$ bridgetown new my-cool-static-project

Step 3: Install JavaScript packages

$ yarn add -D tailwindcss postcss-import postcss-loader autoprefixer postcss

Step 4: Configure postcss.config.js file (put it in the root of your Bridgetown project)

module.exports = {
  plugins: [
    require("postcss-import", {
      path: "frontend/styles",
      plugins: [],
    }),
    require("tailwindcss"),
    require("autoprefixer"),
  ],
};

Step 5: Update webpack.config.js file

Your webpack.config.js css configuration should read as follows (we just need to add postcss-loader after css-loader):

{
  test: /\.(s[ac]|c)ss$/,
    use: [
      MiniCssExtractPlugin.loader,
      "css-loader",
      "postcss-loader",
      {
        loader: "sass-loader",
        options: {
          sassOptions: {
            includePaths: [path.resolve(__dirname, "src/_components")],
          },
        },
      },
    ],
}

Step 6: Add TailwindCSS includes to your frontend/styles/index.scss

@import "tailwindcss/base";
@import "tailwindcss/components";

// Your classes here

@import "tailwindcss/utilities";

Step 6: Run yarn

$ yarn start

You should be in business, continue your design and build out of your static site. Be sure to check the excellent documentation for Bridgetown.

Check out Andrew's guide for further deployment assistance.

Build and deploy a static site with Ruby, Bridgetown, TailwindCSS, and Netlify

Demo Repository Demo Website What is Bridgetown According to their website, Bridgetown...

DEV CommunityAndrew Mason

Here is some of my notes on searching JSON column data with ActiveRecord.

You should be running a newer version of sqlite that has JSON1 extension compiled by default. If you feel your data is not saving as JSON you'll know pretty fast due to having to parse it to JSON on the server side.

The JSON data structure for a project I'm working on looks a bit like below. This is stored in a column named details.

{
    "contact":
    {
        "email":"user@email.com"
    },
    "pageDetails":
    {
        "userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0",
        "pageUrl":"http://localhost:4000/",
        "currentDateTime":"2020-11-12T07:00:04.681Z",
        "ipAddress":"127.0.0.1"
    }
}

To query this you can use JSON1 sqlite extensions within ActiveRecord:

Contact.where("json_extract(contacts.details, '$.contact.email') like '%user@email.com'")

I will update this page as I run into more querying requirements on JSON columns in sqlite.

For more information on JSON1 sqlite extension.

Just a quick fix for vue-loader v15+

If you're developing in Rails in 2018, you're likely using a webpack and a front end framework. This will help you get your vue-loader going from complaining about needing a special loader to compile, back to working.

In your project open up /app/config/webpack/environment.js

const { environment } = require('@rails/webpacker')
const vue = require('./loaders/vue')

environment.loaders.append('vue', vue)
module.exports = environment

You'll probably see something like above.

You'll want to be sure to run yarn add vue-loader and double check in your package.json that your version is v15 or above.

Add these few lines to your environment.js and you'll be back to compiling:

const { environment } = require('@rails/webpacker')
const VueLoaderPlugin = require('vue-loader/lib/plugin')
const vue = require('./loaders/vue')

environment.loaders.append('vue', vue)
environment.plugins.append('VueLoaderPlugin', new VueLoaderPlugin())
module.exports = environment

Further reading: https://github.com/rails/webpacker/blob/master/docs/webpack.md#plugins

In this, hopefully short post, I want to detail how I'm using docker-compose to run webpacker in a Rails 5.1+ environment.

You'll need to run through the docker-compose installation procedures yourself.

Docker paired with docker-compose is an easy way to get a mock production environment spun up really quickly. This assists in developing against a real world-like production environment.

The file below is what I'm using for Dockerfile. This essentially pulls from the lastest ruby docker image, gets some updates and packages we need and installs node and yarn for package management (not the yarn rubygem, that thing is the devil).

FROM ruby:latest

RUN apt-get update -qq && apt-get install -y build-essential apt-transport-https apt-utils

# for nokogiri
RUN apt-get install -y libxml2-dev libxslt1-dev

# for a JS runtime
RUN curl -sL https://deb.nodesource.com/setup_8.x | bash -
RUN apt-get install -y nodejs

# for yarn
RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
RUN echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list
RUN apt-get update -qq && apt-get install -y yarn

ENV APP_HOME /app
RUN mkdir $APP_HOME
WORKDIR $APP_HOME

ADD Gemfile* $APP_HOME/
RUN bundle install

ADD . $APP_HOME

And a simplified production environment setup for our docker-compose YAML file.

version: '2'
services:
  db:
    image: mysql:latest
    environment:
      - MYSQL_ROOT_PASSWORD=T0pS3cretP@ssword
    ports:
      - "3307:3306"

  web:
    build: .
    command: rails s --port 4000 --binding 0.0.0.0
    ports:
      - "4000:4000"
    links:
      - db
    volumes:
      - .:/app

If you haven't built your environment run docker-compose build web. This will process through the Dockerfile and install all the required packages. After all of the system level packages are installed it will run through and install all your gems.

Due to a security issue with earlier versions of the webpacker gem you need to pass the --public LOCALDOCKERIP option when running bin/webpack-dev-server.

bin/webpack-dev-server --public LOCALDOCKERIP:8080

To retrieve your docker instance IP simply login to your instance docker-compose exec NAMEFROMDOCKERCOMPOSEYML bash and run ip addr.

Then all you need to do is run docker-compose up web(replace web with your web frontend name) to spin up all of the instances for the environment. Once that is up, open a new terminal tab and run docker-compose exec up web bash and then run the webpack-dev-server command above to compile and serve your assets.

This can be improved to run when you bring up your environment and will be what I tackle next when I get a moment. Leave any improvements below in the comments. Now, back to webpack.

Oh, the fun it is.

I'm working on an application that will use the apartment gem and I've been needing to drop and recreate the database. I still prefer to work with MySQL and haven't jumped ship to the popular Postgres. MySQL doesn't seem to have as much support for the Apartment gem that Postgres does.

The out of the box functionality for running rails db:reset will simply drop and recreate your development and test environment databases and not touch any Apartment generated tenant databases that may have been created while developing and testing.

I decided to create a rake task since I've found myself dropping the tenant database plenty of times over.

Create a file in lib/tasks, I named it drop_tenants.rake.

Within the rake file add:

namespace :apartment do
	desc 'drop current tenants before performing database reset'
		task :drop_tenants => :environment do
			c = Mysql2::Client.new(host: "localhost", username: "root", password: "password")
			tenant_dbs = User.pluck :subdomain

          tenant_dbs.each do |db|
              r = c.query("DROP DATABASE #{db};")
              puts "Dropped #{db}"
          end
	end
end

This will get you the command rake apartment:drop_tenants so you can prepend this to when you run rake db:reset you'll simply just run rake apartment:drop_tenants db:reset and you're good to go!

Disclaimer: I'm not an SEO expert, I just develop things. I'm speaking with past experience growing and ranking local service businesses.

I've never understood the idea of businesses touting they pay "$$$" per month for SEO. From my experience your ranking moves up organically as your site becomes more set in your target industry and region. For instance, if the search rankings are wide open with not many competitors for specific keywords. You could come in with almost any domain and likely be on the first page result for targeted keywords in 6-10 months with the proper content marketing and website structure.

Here is how I'm planning to bake that in from the get go on Aloha Lawns. If you visit the site you can see the basic link structure starting to take shape. It is important to keep your URL end points keyword happy.

• /services/lawn-mowing
• /services/shrub-trimming
• /services/lawn-fertilization

The URL structure for our services will allow the bot to see multiple keywords associated with our domain name ("aloha lawns lawn mowing", for example). The bot will pick up keywords in the URL as well as check our title and meta tags AND our page content for keywords. I'm sure you've clicked a result because you saw there was multiple keywords bolded on the results page for a specific search listing. However, a majority of our searches will likely be LOCATION keyword specific. So, this won't help us get in the front of potential customers for our service areas.

The title tags should also be unique for each of our pages. Something as simple as "Aloha Lawns | Lawn Mowing", "Aloha Lawns | Shrub Trimming", etc. will suffice. If you wanted to stuff in there a region, you could. ("Aloha Lawns | Hawaii Lawn Mowing | Lawn Mowing")

You get the point. Each of these pages will follow proper keyword and meta descriptions sprinkled with the target keywords for where we want to get ranked. It's important that you come up with unique meta descriptions for each page. Of course these service pages will have useful information about each service offering with proper copy and an action that the user can take to get their service booked.

Key things when building and ranking your site in no particular order:

1. Sitemap, create and submit a sitemap to Google Webmaster Tools
2. Ensure proper meta keywords and descriptions, unique descriptions are best
3. Have as many keywords in your URL structure that makes the most logical sense
4. Be sure to have some keywords throughout the content on your pages you want to get ranked
5. List your business on Google Places/Bing Places and get verified
6. Stuff your pages with Schema Local Business mark-up wherever you list your location address
7. Be sure your pages title tags are unique
8. Responsive and mobile friendly first

Once you have these things in order, you simply ping the search engines to crawl your site. And the waiting game begins. This really is a long term investment that pays off down the road, we're measuring in months, not weeks.

This is going to be a short and sweet update. I had some time to configure a multi-step form for contractor onboading today. It was designed with getting pertinent information from those looking to add additional work to their already existing businesses. It needs a bit more polishing, but, you can get the general idea of how it works from the animation below. I apologize for the flashing screen, my Chrome does that for some reason.

The functionality that this will help us develop later is that we can login to an administrative area and vet our applicants for contractors wanting work. If we approve them, they are emailed and can login and link a Stripe account for payments. With the data we collect here we can then lump contractors with specialities (skills) and assign the right people to the right work. Also, note we are collecting regional preferences so we can assign them to a service region and offer work in their area.

That is all for today.