DEV Community: Derrick Amenuve

Storing Kamal secrets in AWS Secrets Manager and deploying to a cheap Hetzner VPS

Derrick Amenuve — Sat, 23 May 2026 11:55:55 +0000

I ran into a problem with Kamal. My .kamal/secrets file was full of API keys sitting in plaintext on my laptop. Anyone with access could read them all.

TLDR; Use Kamal with AWS Secrets Manager and deploy to a Hetzner VPS. No plaintext secrets, cheap hosting, compliance happy.

The problem

Kamal is great for deploying apps. But by default secrets are in a plaintext file. For SOC 2 and GDPR that does not work. You need a managed store. I went with AWS Secrets Manager.

But then I hit another issue. The kamal secrets fetch --adapter aws_secrets_manager command with --from expects each key to be its own AWS secret. If you store everything as one JSON blob (like I did), you get:

ERROR (RuntimeError): myapp/production/secrets//DEEPGRAM_API_KEY: Secrets Manager can't find the specified secret.

Step 1: Hetzner VPS

Hetzner CAX series starts at around 4 euro a month. I use the CX22 with 2 vCPUs and 4GB RAM. Enough for production.

# On your Hetzner server
apt update && apt install -y docker.io

# Copy your SSH key so Kamal can connect
ssh-copy-id root@your-server-ip

Your config/deploy.yml:

servers:
  web:
    hosts:
      - yourdomain.com

proxy:
  ssl: true
  hosts:
    - yourdomain.com
  healthcheck:
    path: /health/ready

registry:
  server: docker.io
  username: your-docker-user
  password:
    - KAMAL_REGISTRY_PASSWORD

You need a Docker Hub account and a personal access token for KAMAL_REGISTRY_PASSWORD.

Step 2: Create the secret in AWS

In the AWS Secrets Manager Console:

Go to Secrets Manager > Store a new secret
Select "Other type of secret"
Switch to plaintext tab and paste your JSON

{
  "DEEPGRAM_API_KEY": "your_deepgram_key",
  "ASSEMBLY_AI_API_KEY": "your_assemblyai_key",
  "REDIS_URL": "redis://:password@your-redis:6379",
  "KAMAL_REGISTRY_PASSWORD": "your_docker_token"
}

Name it myapp/production/secrets
Click Store

Pick a region close to your server. If your Hetzner box is in Germany, use eu-central-1 (Frankfurt). Keeps latency low and GDPR happy.

Step 3: IAM user for your laptop

Your laptop needs permission to read the secret during deploy.

Go to IAM > Users > Create user
Name it kamal-deploy
Uncheck console access (CLI only)
Create a group called secrets-manager with the SecretsManagerReadWrite policy
Add an inline policy for batch reading:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret",
        "secretsmanager:BatchGetSecretValue",
        "secretsmanager:ListSecrets"
      ],
      "Resource": "*"
    }
  ]
}

Add your user to the group

IAM policies can take a minute to propagate. If it fails at first, wait 30 seconds and try again.

Step 4: Configure AWS CLI

aws configure
# AWS Access Key ID: paste from IAM user
# AWS Secret Access Key: paste
# Default region name: eu-central-1
# Default output format: json

Test it:

aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text | head -c 50

You should see the start of your JSON.

Step 5: Format your .kamal/secrets file

This is where I got stuck. The --from flag wants one AWS secret per key. Having 20 separate secrets is annoying. Check the Kamal secrets docs for more on this.

Instead I use the AWS CLI with Python extraction. Each line is self contained:

# AWS Secrets Manager: myapp/production/secrets (eu-central-1)
DEEPGRAM_API_KEY=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['DEEPGRAM_API_KEY'])" "$(aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text)")
ASSEMBLY_AI_API_KEY=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['ASSEMBLY_AI_API_KEY'])" "$(aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text)")
REDIS_URL=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['REDIS_URL'])" "$(aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text)")
KAMAL_REGISTRY_PASSWORD=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['KAMAL_REGISTRY_PASSWORD'])" "$(aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text)")

Each line fetches the full JSON and extracts one key. Kamal evaluates each line in its own subshell so there are no shared variables between lines. This works.

You can also use jq if you prefer:

DEEPGRAM_API_KEY=$(aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text | jq -r '.DEEPGRAM_API_KEY')

Step 6: Deploy

kamal deploy

Kamal fetches secrets from AWS during deploy and injects them into your container. No plaintext file ever touches the server.

Production and staging

I use a different AWS secret per environment. Both pull from AWS no plaintext anywhere.

# .kamal/secrets  (used by kamal deploy)
DEEPGRAM_API_KEY=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['DEEPGRAM_API_KEY'])" "$(aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text)")
KAMAL_REGISTRY_PASSWORD=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['KAMAL_REGISTRY_PASSWORD'])" "$(aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text)")

# .kamal/secrets.staging  (used by kamal deploy -d staging)
DEEPGRAM_API_KEY=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['DEEPGRAM_API_KEY'])" "$(aws secretsmanager get-secret-value --secret-id myapp/staging/secrets --query SecretString --output text)")
KAMAL_REGISTRY_PASSWORD=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['KAMAL_REGISTRY_PASSWORD'])" "$(aws secretsmanager get-secret-value --secret-id myapp/staging/secrets --query SecretString --output text)")

Only the secret name changes between files. myapp/production/secrets for production, myapp/staging/secrets for staging. Run kamal deploy -d staging and Kamal reads from the staging file.

Both secrets live in AWS. No staging credentials in plaintext either. This matters for SOC 2 because auditors check every environment.

Done

No more secrets in plaintext. SOC 2 and GDPR requirements met. Hetzner bill stays under 5 euro a month.

Big thanks to the AWS docs team, the Kamal maintainers, and Hetzner for keeping hosting affordable. Hope this saves you the same headaches I ran into. Now back to building.

Storing Kamal secrets in AWS Secrets Manager and deploying to a cheap Hetzner VPS

Derrick Amenuve — Sat, 23 May 2026 11:48:51 +0000

I ran into a problem with Kamal. My .kamal/secrets file was full of API keys sitting in plaintext on my laptop. Anyone with access could read them all.

TLDR; Use Kamal with AWS Secrets Manager and deploy to a Hetzner VPS. No plaintext secrets, cheap hosting, compliance happy.

The problem

Kamal is great for deploying apps. But by default secrets are in a plaintext file. For SOC 2 and GDPR that does not work. You need a managed store. I went with AWS Secrets Manager.

ERROR (RuntimeError): myapp/production/secrets//DEEPGRAM_API_KEY: Secrets Manager can't find the specified secret.

Step 1: Hetzner VPS

Hetzner CAX series starts at around 4 euro a month. I use the CX22 with 2 vCPUs and 4GB RAM. Enough for production.

# On your Hetzner server
apt update && apt install -y docker.io

# Copy your SSH key so Kamal can connect
ssh-copy-id root@your-server-ip

Your config/deploy.yml:

servers:
  web:
    hosts:
      - runtime.yourdomain.com

proxy:
  ssl: true
  hosts:
    - runtime.yourdomain.com
  healthcheck:
    path: /health/ready

registry:
  server: docker.io
  username: your-docker-user
  password:
    - KAMAL_REGISTRY_PASSWORD

You need a Docker Hub account and a personal access token for KAMAL_REGISTRY_PASSWORD.

Step 2: Create the secret in AWS

In the AWS Secrets Manager Console:

Go to Secrets Manager > Store a new secret
Select "Other type of secret"
Switch to plaintext tab and paste your JSON

{
  "DEEPGRAM_API_KEY": "your_deepgram_key",
  "ASSEMBLY_AI_API_KEY": "your_assemblyai_key",
  "REDIS_URL": "redis://:password@your-redis:6379",
  "KAMAL_REGISTRY_PASSWORD": "your_docker_token"
}

Name it myapp/production/secrets
Click Store

Pick a region close to your server. If your Hetzner box is in Germany, use eu-central-1 (Frankfurt). Keeps latency low and GDPR happy.

Step 3: IAM user for your laptop

Your laptop needs permission to read the secret during deploy.

Go to IAM > Users > Create user
Name it kamal-deploy
Uncheck console access (CLI only)
Create a group called secrets-manager with the SecretsManagerReadWrite policy
Add an inline policy for batch reading:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret",
        "secretsmanager:BatchGetSecretValue",
        "secretsmanager:ListSecrets"
      ],
      "Resource": "*"
    }
  ]
}

Add your user to the group

IAM policies can take a minute to propagate. If it fails at first, wait 30 seconds and try again.

Step 4: Configure AWS CLI

aws configure
# AWS Access Key ID: paste from IAM user
# AWS Secret Access Key: paste
# Default region name: eu-central-1
# Default output format: json

Test it:

aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text | head -c 50

You should see the start of your JSON.

Step 5: Format your .kamal/secrets file

This is where I got stuck. The --from flag wants one AWS secret per key. Having 20 separate secrets is annoying. Check the Kamal secrets docs for more on this.

Instead I use the AWS CLI with Python extraction. Each line is self contained:

# AWS Secrets Manager: myapp/production/secrets (eu-central-1)
DEEPGRAM_API_KEY=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['DEEPGRAM_API_KEY'])" "$(aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text)")
ASSEMBLY_AI_API_KEY=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['ASSEMBLY_AI_API_KEY'])" "$(aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text)")
REDIS_URL=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['REDIS_URL'])" "$(aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text)")
KAMAL_REGISTRY_PASSWORD=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['KAMAL_REGISTRY_PASSWORD'])" "$(aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text)")

Each line fetches the full JSON and extracts one key. Kamal evaluates each line in its own subshell so there are no shared variables between lines. This works.

You can also use jq if you prefer:

DEEPGRAM_API_KEY=$(aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text | jq -r '.DEEPGRAM_API_KEY')

Step 6: Deploy

kamal deploy

Kamal fetches secrets from AWS during deploy and injects them into your container. No plaintext file ever touches the server.

Production and staging

I use a different AWS secret per environment. Both pull from AWS no plaintext anywhere.

# .kamal/secrets  (used by kamal deploy)
DEEPGRAM_API_KEY=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['DEEPGRAM_API_KEY'])" "$(aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text)")
KAMAL_REGISTRY_PASSWORD=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['KAMAL_REGISTRY_PASSWORD'])" "$(aws secretsmanager get-secret-value --secret-id myapp/production/secrets --query SecretString --output text)")

# .kamal/secrets.staging  (used by kamal deploy -d staging)
DEEPGRAM_API_KEY=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['DEEPGRAM_API_KEY'])" "$(aws secretsmanager get-secret-value --secret-id myapp/staging/secrets --query SecretString --output text)")
KAMAL_REGISTRY_PASSWORD=$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['KAMAL_REGISTRY_PASSWORD'])" "$(aws secretsmanager get-secret-value --secret-id myapp/staging/secrets --query SecretString --output text)")

Only the secret name changes between files. myapp/production/secrets for production, myapp/staging/secrets for staging. Run kamal deploy -d staging and Kamal reads from the staging file.

Both secrets live in AWS. No staging credentials in plaintext either. This matters for SOC 2 because auditors check every environment.

Done

No more secrets in plaintext. SOC 2 and GDPR requirements met. Hetzner bill stays under 5 euro a month.

Big thanks to the AWS docs team, the Kamal maintainers, and Hetzner for keeping hosting affordable. Hope this saves you the same headaches I ran into. Now back to building.

Resolving ActiveStorage URL Generation Between Rails and Avo admin gem

Derrick Amenuve — Tue, 15 Aug 2023 19:16:49 +0000

I've been working on my project Modatongue and hit a roadblock with Active Storage. Images were displaying fine in lessons or my main rails application, but not in my Avo admin! 😭

TLDR;
Just change line 3 of your app/views/active_storage/_blobs.html.erb to use main_app.url_

My Battle with Active Storage (and How I Won!)
Like I mentioned earlier the Images were displaying fine in my lessons or inside the main rails app, but not in my Avo admin or when I logged into my admin interface! 😭

<figure class="attachment attachment--<%= blob.representable? ? "preview" : "file" %> attachment--<%= blob.filename.extension %>">
  <% if blob.representable? %>
    <%= image_tag blob.representation(resize_to_limit: local_assigns[:in_gallery] ? [ 800, 600 ] : [ 1024, 768 ]) %>
  <% end %>

  <figcaption class="attachment__caption">
    <% if caption = blob.try(:caption) %>
      <%= caption %>
    <% else %>
      <span class="attachment__name"><%= blob.filename %></span>
      <span class="attachment__size"><%= number_to_human_size blob.byte_size %></span>
    <% end %>
  </figcaption>
</figure>

The above code for my blob partial(which is likely going to be your default when you install active storage). This works in Rails views, but not Avo which expects blob objects to respond to to_model. Avo admin cried undefined method 'to_model'. Ugh, why?! 🤯

After a lot of trial and error, I realized Avo uses different helpers. So I tried bypassing them directly with:

<%= image_tag main_app.url_for(blob) %>

so now my blob partial will look like:

<figure class="attachment attachment--<%= blob.representable? ? "preview" : "file" %> attachment--<%= blob.filename.extension %>">
  <% if blob.representable? %>
    <%= image_tag main_app.url_for(blob.representation(resize_to_limit: local_assigns[:in_gallery] ? [ 800, 600 ] : [ 1024, 768 ])) %>
  <% end %>

  <figcaption class="attachment__caption">
    <% if caption = blob.try(:caption) %>
      <%= caption %>
    <% else %>
      <span class="attachment__name"><%= blob.filename %></span>
      <span class="attachment__size"><%= number_to_human_size blob.byte_size %></span>
    <% end %>
  </figcaption>
</figure>

The Solution
The key was to bypass both helpers and generate the URL directly from Rails.

This works because main_app references the root Rails application context:

<%= image_tag main_app.url_for(blob.representation(resize_to_limit: local_assigns[:in_gallery] ? [ 800, 600 ] : [ 1024, 768 ])) %>

Now url_for generates the URL correctly for any ActiveStorage attachment, working identically in both Rails and Avo views.
By leveraging the core Rails URL generation, a single rendering approach can work consistently across any frameworks layered on top of Rails. This keeps view code DRY and avoids compatibility issues.

Eureka! It worked 🎉
Big props to the chatbots who helped clue me in - ChatGPT, Poe and especially Bard who provided the final hint. What a rollercoaster ride but so satisfying to crack it myself! 🙌

I hope this helps you and feel free to say hi on Twitter! Now back to building Modatongue.

There is not only one right way

Derrick Amenuve — Wed, 12 May 2021 09:32:32 +0000

Many times when we want to work on design projects we normally think of following the best practices UX design process. This is a worrying subject for almost every designer especially beginners, we tend to ask ourselves if the flow or pattern we use is the best practice when it comes to UX design.

I have come to understand that there isn't a one-way process when it comes to designing websites, web apps or mobile apps. Your process will highly depend on the type of product you’re designing. Every project requires different approaches; the approach to designing a website for an alumni network of an institution or your alma mater differs from the way we design a cryptocurrency app(it's the new thing being talked about😀), for example.

I think what we should really focus on as designers are to apply the concept of Design Thinking and the principles of principles of design. The design thinking process has five stages in it: empathize, define, ideate, prototype, and test
This should be great for any kind of project ✌🏽.

My next post will be a brief on the process I used when designing a website for my Alumni network. Stay tuned, mia ga do go🤝 (meaning we will meet again, translated from Ewe- a Ghanaian language)