DEV Community: Jurijs Ivolga

How to manage Let's Encrypt certificate on EC2 instance

Jurijs Ivolga — Tue, 18 Nov 2025 12:21:10 +0000

In this guide, I’ll provide a short manual on how to create and manage Let’s Encrypt certificates on your EC2 instance using Lego (a Let's Encrypt/ACME client and library written in Go). We’ll use the DNS-01 challenge, and the instance will have an appropriate IAM role so only the instance itself can manage the _acme-challenge TXT record for the domain.

Why use Let's Encrypt on EC2?

Why even bother using Let’s Encrypt in AWS? First of all — simpler setup. You don’t need an ALB or CloudFront, which also means lower cost. Sometimes, your application isn’t something you can easily put behind a load balancer — for example, any SIP proxy. So in some cases, you’ll want Let’s Encrypt certs directly on the EC2 instance.

Why DNS-01 challenge?

If you’re running a SIP application, why open port 80 at all if you don’t need to? Or maybe port 80 is already being used by another service. Personally, I just prefer the DNS-01 challenge — fewer firewall holes to worry about.

Overview

We’ll create an instance profile and assign it to our EC2 instance so the instance itself can have permissions to add or remove DNS records, which is required for the DNS-01 challenge.

Requirements

I assume you already have an EC2 instance up and running. Here's an example Terraform configuration to spin up a test instance:

terraform {  
  required_providers {  
    aws = {  
      source = "hashicorp/aws"  
    }  
  }  
}  

provider "aws" {  
  region  = "us-east-1"  
  profile = "dev"  
}  

resource "aws_key_pair" "jurijs" {  
  key_name   = "jurijs-key"  
  public_key = "ssh-rsa AAAAB3N..."  
}  

resource "aws_eip" "dev" {  
  instance = aws_instance.dev.id  
  domain   = "vpc"  
}  

output "aws_eip" {  
  value = aws_eip.dev.public_ip  
}  

output "aws_private" {  
  value = aws_instance.dev.private_ip  
}  

resource "aws_instance" "dev" {  
  ami                    = "ami-0facb4427ff2f68d4"  
  instance_type          = "t2.micro"  
  key_name               = aws_key_pair.jurijs.key_name  
  vpc_security_group_ids = [aws_security_group.dev.id]  
}  

resource "aws_security_group" "dev" {  
  name_prefix = "dev"  
}  

resource "aws_security_group_rule" "outbound" {  
  security_group_id = aws_security_group.dev.id  
  description       = "all-outbound-allowed"  
  from_port         = 0  
  to_port           = 0  
  protocol          = "-1"  
  type              = "egress"  
  cidr_blocks       = ["0.0.0.0/0"]  
}  

resource "aws_security_group_rule" "SSH" {  
  security_group_id = aws_security_group.dev.id  
  description       = "Allow SSH from everywhere"  
  from_port         = 22  
  to_port           = 22  
  protocol          = "tcp"  
  type              = "ingress"  
  cidr_blocks       = ["0.0.0.0/0"]  
}

Create IAM profile for Lego

For the instance profile, you can use my Terraform module from GitHub:

https://github.com/os11k/terraform-iam-lego

Then add the following:

module "lego-iam" {  
  source     = "../modules/lego-iam"  
  hostname   = ["my-domain.com", "www.my-domain.com"]  
  hostedzone = "7AZKFFF"  
}

And make sure the EC2 instance has the IAM instance profile assigned:

resource "aws_instance" "instance-with-letsencrypt" {  
  ...  
  iam_instance_profile = module.lego-iam.instance-profile-name  
  ...  
}

Install Lego and Issue the Certificate

Install the necessary packages and issue the certificate with the following commands:

curl -s https://api.github.com/repos/go-acme/lego/releases/latest | grep "browser_download_url" | grep "linux_amd64.tar.gz" | cut -d '"' -f 4 | xargs curl -LO -#  
tar xzvf lego_v*.tar.gz  
install lego /usr/local/bin/  

export AWS_REGION=us-east-1  

/usr/local/bin/lego --accept-tos --dns route53 --email="my-gmail@gmail.com" --domains="my-domain.com" --domains="www.my-domain.com" --path="/etc/lego" run

Validate the Certificate

To verify the certificate, run:

cat /etc/lego/certificates/my-domain.com.crt

You should see output similar to:

-----BEGIN CERTIFICATE-----  
MIIDxDCCA0mgAwIBAgISBrctmxC+XMJfDQGtEo89F6aaMAoGCCqGSM49BAMDMDIx  
...  
-----END CERTIFICATE-----  

-----BEGIN CERTIFICATE-----  
MIIEVzCCAj+gAwIBAgIRAIOPbGPOsTmMYgZigxXJ/d4wDQYJKoZIhvcNAQELBQAw  
...  
-----END CERTIFICATE-----

The first certificate is for my-domain.com and www.my-domain.com.

Visit https://certdecoder.com/ to verify the certificate. You should see that the Common Name is my-domain.com and the Subject Alternative Names (SANs) include both my-domain.com and www.my-domain.com.

Note: In the screenshot below, the example shows certdecoder.com instead of my-domain.com. The certificate is valid for 90 days.

The second certificate is Let’s Encrypt’s root certificate. You can inspect it if desired, though it is not essential for this guide.

Renewal via Cron

Set up a cron job for automatic renewal with these entries:

AWS_REGION=us-east-1  
12 1 * * 6 /usr/local/bin/lego --dns route53 --email="my-gmail@gmail.com" --domains="my-domain.com" --domains="www.my-domain.com" --path="/etc/lego" renew >> /var/log/lego.log 2>&1  
12 2 * * 6 systemctl reload nginx.service

The first line ensures the AWS region is set.
The second line handles the renewal process.
The third line reloads nginx so that any new certificate is applied. (If you’re using another service like Apache or Kamailio, replace this command accordingly.)

Conclusion

You now have Let’s Encrypt set up directly on your EC2 instance using the DNS-01 challenge with the proper IAM permissions. Certificates are issued and automatically renewed via cron.

Keep an eye on /var/log/lego.log — if renewal fails, you’ll find useful details there for troubleshooting.

🍌 I Built a Tool Directory Where Things Go Bananas (and You Can Too!)

Jurijs Ivolga — Sat, 06 Sep 2025 15:06:55 +0000

Today's the day I finished my weird little tool directory:

banana.dog 🎉

It was quite the journey, let me tell you.

The Over-Engineering Phase 🚀

At the beginning, I had BIG PLANS™. I was going to use:

Astro with all the bells and whistles
AI to scrape websites and auto-generate descriptions
Fancy animations everywhere
A complex submission system
Probably blockchain somehow (kidding... or am I?)

But guess what? I got so overwhelmed by all that shiny tech, I never had the time or energy to actually build the thing. Classic developer move, right? 🤦‍♂️

The "Wait, Let's Actually Ship This" Phase 🍌

So I went full banana and decided to:

Keep it plain HTML (gasp!)
Build it using merge requests in GitLab
Add a validation bot that checks if submissions follow the rules

Sometimes the simplest solution is the best solution. Who knew?

The Plot Twist 📧

Here's the funny part: I had quite a few email requests from people wanting their tools featured. Now that it's open source, let's see how many actually open MRs.

My prediction? About 3. Maybe 4 if we're being optimistic. 😄

Want Your Weird Tool Featured? 🛠️

If you've built something:

Useful, useless, or somewhere in between
Weird, wonderful, or slightly unhinged
That actually works (mostly)

Just open a merge request here: gitlab.com/jurijs.ivolga/banana-www

The automated banana bot will check your submission, and if it passes, your tool joins the banana brigade!

What I Learned 🎓

Perfect is the enemy of done - My simple HTML site is live, while my Astro masterpiece lives only in my imagination
Validation bots are fun - Mine posts banana emojis in MR comments
Sometimes you just need to go bananas 🍌

Check out banana.dog and submit your weird tools. Or don't. I'm not your boss.

P.S. - Yes, the domain name came first. No, I don't regret it.

How I sped up my WordPress from 800ms to 30ms for FREE!

Jurijs Ivolga — Sun, 24 Aug 2025 17:12:28 +0000

I was frustrated with my WordPress site's slow response times, until I discovered a WordPress Cache Plugin. And it change everything, at least for me!

The Problem 🐌

My WordPress site was struggling with response times:

Mostly between 200-400ms (acceptable)
Frequent spikes above 1 second
Often hovering around 800ms (disappointing)

The Solution ⚡

After one night of testing, I achieved incredible results using Cloudflare

Super Page Cache WordPress plugin:
- Before: 200-800ms+ response times
- After: Consistent 30-200ms response times
- Performance comparable to static websites hosted on S3!

Quick Setup Guide 🚀

Prerequisites

WordPress website
Free Cloudflare account (cloudflare.com)

Step 1: Add Domain to Cloudflare

Log into Cloudflare and add your domain
Select the free plan
Update your domain's nameservers at your registrar
Wait for activation email

Step 2: Fix Common Issues

If you encounter ERR_TOO_MANY_REDIRECTS:

Go to SSL/TLS settings in Cloudflare
Change encryption mode from "Flexible" to "Full" or "Full (Strict)"
This prevents redirect loops between Cloudflare and your server

Step 3: Install Super Page Cache Plugin

In WordPress admin → Plugins → Add New
Search for "Super Page Cache"
Install and activate
Click "ENABLE PAGE CACHING NOW"

Important: Disable any other caching plugins first!

Step 4: Connect to Cloudflare

Get your Cloudflare API key:
- Profile → API Tokens → View Global API Key
In Super Page Cache settings:
- Go to "Cloudflare (CDN & Edge Caching)"
- Enter your Cloudflare email and API key
- Select your domain
- Click "Continue"

Step 5: Verify Setup

Click "TEST CACHE" in the plugin settings. You should see:

✅ Cloudflare Page Caching is working properly
✅ Disk Page Caching is functional

Results 📊

The transformation was immediate:

Deployment at 1:00 AM
All requests now between 30-200ms
Performance matches static site hosting
Zero cost - completely free solution!

Key Takeaways 💡

This isn't a silver bullet for all performance issues
Completely free solution with enterprise-level performance gains

How to Replace SSH with AWS Session Manager

Jurijs Ivolga — Tue, 24 Jun 2025 14:57:51 +0000

Ever wanted to simplify access management to your EC2 instances? AWS Session Manager might be the solution you're looking for.

Why Ditch SSH?

As your infrastructure grows, managing SSH access becomes a pain:

Creating/deleting users on multiple instances
Managing SSH keys
Dual access management (AWS + EC2)
Complex offboarding processes

The Session Manager Solution

Session Manager combines AWS and EC2 access into one tool. Users only need AWS credentials to access instances. Remove AWS access = remove EC2 access. Simple.

Setup Overview

I followed AWS's official guide but simplified it for practical use.

What You Get

✅ No SSH required - Remove port 22 from security groups

✅ No SSH keys - Zero key management

✅ SSM Agent - Pre-installed on most AMIs

The Code

I created a Terraform module after fixing issues in the AWS sample.

Module: terraform-session-manager

Main Configuration

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5"
    }
  }
}

provider "aws" {
  region  = "us-east-1"
  profile = "my-profile-name"
}

module "ssm" {
  source = "../modules/ssm"
}

output "ssm_profile_name" {
  value = module.ssm.ssm-profile-name
}

Region-Specific Setup

Session Manager is region-specific, so you need this for each region:

provider "aws" {
  region  = "us-east-1"
  profile = "my-profile-name"
  alias   = "useast1"
}

resource "aws_ssm_document" "session_manager_prefs_useast1" {
  provider = aws.useast1

  name            = "SSM-SessionManagerRunShell"
  document_type   = "Session"
  document_format = "JSON"

  content = <<DOC
{
    "schemaVersion": "1.0",
    "description": "SSM document to house preferences for session manager",
    "sessionType": "Standard_Stream",
    "inputs": {
        "s3BucketName": "${module.ssm.ssm_s3_bucket_id}",
        "s3KeyPrefix": "AWSLogs/ssm_session_logs",
        "s3EncryptionEnabled": true,
        "cloudWatchLogGroupName": "",
        "runAsEnabled": true,
        "runAsDefaultUser": "${var.user}",
        "shellProfile": {
          "windows": "",
          "linux": "exec /bin/bash\ncd /home/${var.user}"
        },
        "idleSessionTimeout": "20"
    }
}
DOC
}

Adding More Regions

For additional regions (like us-east-2), just add:

provider "aws" {
  region  = "us-east-2"
  profile = "my-profile-name"
  alias   = "useast2"
}

resource "aws_ssm_document" "session_manager_prefs_useast2" {
  provider = aws.useast2
  # ... same document config as above
}

Key Benefits

🔒 Security: Encrypted sessions, centralized access control

⚡ Simplicity: One place to manage all access

📊 Auditing: All sessions logged to S3

🚀 Scalability: Works across unlimited instances

Gotchas

Internet access required for private instances
Region-specific configuration needed
SSM Agent must be running (usually is by default)

Useful Resources

Have you tried Session Manager? What's your preferred way to manage EC2 access? Let me know in the comments!

Found this helpful? I'd appreciate if you follow me for more AWS and infrastructure content! 🚀

Originally published at Cyberpunk Tools Blog.

Banana.dog back from the dead

Jurijs Ivolga — Tue, 01 Apr 2025 13:58:32 +0000

It’s April 1st — the perfect day for doing something a little foolish.

So here it is: I brought banana.dog back from the dead.

It used to be a Mastodon server.

Now? It’s being reborn as a weird, wonderful, slightly chaotic directory of tools — indie projects, small utilities, personal dev hacks, whatever deserves a little more spotlight.

Why?

Because I built certdecoder.com and couldn’t find a decent place to submit it.

So I said screw it — I’ll build my own. With blackjack and hookers.

It’s not finished, and it’s not functional.

But it’s live. And sometimes, that’s enough.

So let’s celebrate — the April 1st (re)birth of banana.dog 🐶🍌

Jekyll Blog with Terraform (OpenTofu) Using GitLab Pipelines

Jurijs Ivolga — Sun, 16 Mar 2025 13:23:11 +0000

In this guide, I will provide a short manual for deploying a static blog, in this case Jekyll (with minor changes, you should be able to make it work for any other static website), to Amazon S3 using GitLab pipelines. All infrastructure will be managed in Terraform (or OpenTofu, as in our case).

This manual assumes that you are using Route 53 as your DNS provider, and all AWS infrastructure will be deployed to the US East (N. Virginia) region. If you want to use a different region, set the aws_region variable accordingly in blog.tfvars.

Step 1: Credential Setup and Creating the S3 Bucket

First, we need to set up AWS credentials and ensure that AWS CLI and Terraform (or OpenTofu) are already installed.

I used this manual to install OpenTofu:

Installing OpenTofu on .deb-based Linux

Here is the installation code:

# Download the installer script:
curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh -o install-opentofu.sh
# Alternatively: wget --secure-protocol=TLSv1_2 --https-only https://get.opentofu.org/install-opentofu.sh -O install-opentofu.sh

# Give it execution permissions:
chmod +x install-opentofu.sh

# Please inspect the downloaded script

# Run the installer:
./install-opentofu.sh --install-method deb

# Remove the installer:
rm -f install-opentofu.sh

To install Terraform, use this guide:

Install Terraform

sudo apt-get update && sudo apt-get install -y gnupg software-properties-common
wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update
sudo apt-get install terraform

To install AWS CLI, follow the instructions here:

Installing or updating to the latest version of the AWS CLI

apt install unzip
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

Once the installation is complete, set up your AWS credentials using the profile prod (you can choose any profile name, but prod is used for this manual):

aws configure --profile prod

After setting up your credentials, verify them by running cat ~/.aws/credentials — it should return something like:

[prod]
aws_access_key_id=AXXXXXXXXX
aws_secret_access_key=xxxxxxxxxxxxxxxxxxx

Test the credentials with the following command to ensure they work:

aws sts get-caller-identity --profile prod

You should see output similar to:

{
    "UserId": "AXXXXXXXXX",
    "Account": "8XXXXXXXXX",
    "Arn": "arn:aws:iam::8XXXXXXXXX:user/jurijsxxxxxxx"
}

Now, create the S3 bucket where the Terraform state file will be saved. Keep in mind that this name might already be taken, so use something unique. If you use a different name, make sure to update main.tf accordingly.:

aws s3api create-bucket --bucket "myblog-tf-state" --region "us-east-1" --acl private --profile prod

The output should look something like this:

{
    "Location": "/myblog-tf-state"
}

Step 2: Setup Terraform Code

Most of the Terraform code was taken from the following repository:

GitHub terraform-aws-static-site

The author's blog post explains in detail what each part of the code does:

pirx.io - Automated Static Site Deployment in AWS Using Terraform

However, I encountered a few issues with this code. First, it was missing the mandatory aws_s3_bucket_ownership_controls resource. The solution was to add the aws_s3_bucket_ownership_controls resource and update the aws_s3_bucket_acl accordingly. Here is the full code snippet for the relevant part:

resource "aws_s3_bucket" "static_site" {
  bucket = var.domain
}

resource "aws_s3_bucket_ownership_controls" "static_site" {
  bucket = aws_s3_bucket.static_site.id
  rule {
    object_ownership = "BucketOwnerPreferred"
  }
}

resource "aws_s3_bucket_acl" "static_site" {
  depends_on = [aws_s3_bucket_ownership_controls.static_site]

  bucket = aws_s3_bucket.static_site.id
  acl    = "private"
}

Additionally, we need to create an IAM user for deploying the blog via the GitLab pipeline. I copied the relevant code from here:

GitHub terraform-aws-s3-static-site

resource "aws_iam_user" "deploy" {
  name = "${var.domain}-deploy"
  path = "/"
}

resource "aws_iam_access_key" "deploy" {
  user = aws_iam_user.deploy.name
}

resource "aws_iam_user_policy" "deploy" {
  name   = "deploy"
  user   = aws_iam_user.deploy.name
  policy = data.aws_iam_policy_document.deploy.json
}

Add this code snippet to outputs.tf to output the credentials needed for the pipeline:

output "AWS_ACCESS_KEY_ID" {
  sensitive   = true
  description = "The AWS Access Key ID for the IAM deployment user."
  value       = aws_iam_access_key.deploy.id
}

output "AWS_SECRET_ACCESS_KEY" {
  sensitive   = true
  description = "The AWS Secret Key for the IAM deployment user."
  value       = aws_iam_access_key.deploy.secret
}

To make things easier, I’ve consolidated all the code into a single repository:

GitHub jekyll-terraform-aws-s3

I chose to use a monolithic approach instead of modules for simplicity. You just need to set at least the domain and route53_zone_id variables in blog.tfvars and you're ready to deploy the infrastructure in AWS:

tofu init
tofu plan -var-file="blog.tfvars"
tofu apply -var-file="blog.tfvars"

or using Terraform:

terraform init
terraform plan -var-file="blog.tfvars"
terraform apply -var-file="blog.tfvars"

Once applied, the output will display variables to use later in the pipeline:

AWS_ACCESS_KEY_ID = <sensitive>
AWS_SECRET_ACCESS_KEY = <sensitive>
CLOUDFRONT_DISTRIBUTION_ID = "EXXXXXX"
S3_BUCKET = "my-site.com"

To retrieve sensitive variables, run:

tofu output --json

or using Terraform:

terraform output --json

Step 3: Setup GitLab Pipeline

The pipeline I use is directly copied from here:

SchenkTech Blog - Hosting a Jekyll Site in S3 Part 2

Since the author didn’t provide a Git repository for the code, I created one myself:

GitLab deploy-jekyll-to-s3

When you fork that repository or copy the files, you will need to set the following variables in GitLab CI/CD settings. Ensure they are masked and protected to safeguard sensitive information:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
CLOUDFRONT_DISTRIBUTION_ID
S3_BUCKET

Next, add your actual Jekyll code to the repository, commit, and push it:

cd ~
git clone https://github.com/daattali/beautiful-jekyll.git
rm -Rf ./beautiful-jekyll/.git* ./beautiful-jekyll/README.md
cp -a ./beautiful-jekyll/* ./deploy-jekyll-to-s3/  # Assuming your code with the pipeline is in ~/deploy-jekyll-to-s3 directory
cd ~/deploy-jekyll-to-s3
git add .
git commit -m "added jekyll"
git push

And you're done! Once the build completes, your website will be deployed, and you should see the Beautiful Jekyll template live.

Originally published at Cyberpunk Tools Blog.

Using Grafana Loki as a Centralized Logging Solution

Jurijs Ivolga — Wed, 12 Mar 2025 12:25:23 +0000

Today, I'll explain how to use Grafana Loki as a centralized logging solution for all your Docker containers. As your infrastructure grows and more containers are added, troubleshooting via logs becomes increasingly important. You might need to diagnose issues like a database failure or an SSL certificate that didn’t renew. Personally, I used to check logs with the docker logs command, but this approach isn’t efficient. Imagine trying to filter logs for a specific time window — like 12:00-12:05 UTC on May 5 — or investigating issues that span multiple containers, such as when a database failure causes an error on an Nginx container. Instead of manually piecing logs together from different machines, it’s more efficient to store all logs centrally, enabling simultaneous searches across all containers. With Loki, you can set up alerts, filter specific log entries using regex, and much more.

In this post, I'll walk you through how I set up a centralized logging solution for all my Docker containers using Grafana Loki.

Step 1: Install Loki

I recommend installing Loki with Docker Compose. Here is Grafana's default docker-compose.yaml file for Loki:

Grafana Loki Docker Compose Documentation

And here is the code itself:

Grafana Loki Docker Compose YAML

Since we don’t need Promtail (Loki's log collector), we can comment that part out. I'll also add volume configurations:

version: "3"

networks:
  loki:

services:
  loki:
    image: grafana/loki:2.9.2
    ports:
      - "3100:3100"
    command: -config.file=/etc/loki/local-config.yaml
    volumes:
      - loki_data:/loki
    networks:
      - loki

#  promtail:
#    image: grafana/promtail:2.9.2
#    volumes:
#      - /var/log:/var/log
#    command: -config.file=/etc/promtail/config.yml
#    networks:
#      - loki

  grafana:
    environment:
      - GF_PATHS_PROVISIONING=/etc/grafana/provisioning
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
    entrypoint:
      - sh
      - -euc
      - |
        mkdir -p /etc/grafana/provisioning/datasources
        cat <<EOF > /etc/grafana/provisioning/datasources/ds.yaml
        apiVersion: 1
        datasources:
        - name: Loki
          type: loki
          access: proxy 
          orgId: 1
          url: http://loki:3100
          basicAuth: false
          isDefault: true
          version: 1
          editable: false
        EOF
        /run.sh
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
    networks:
      - loki

volumes:
    grafana_data: {}
    loki_data: {}

Step 2: Configure Containers to Send Logs to Loki

Once the Loki container is running, configure your containers to push logs to Loki. First, install the Docker plugin and restart the Docker engine:

docker plugin install grafana/loki-docker-driver:latest --alias loki --grant-all-permissions
systemctl restart docker

Verify that the plugin is installed:

docker plugin ls

You should see your newly installed Docker plugin:

ID             NAME          DESCRIPTION           ENABLED
ddd2367c8693   loki:latest   Loki Logging Driver   true

Next, configure each container to send logs to Loki by adding these lines in your docker-compose file (replace loki-ip with the actual IP of your Loki server):

logging:
  driver: loki
  options:
    loki-url: http://loki-ip:3100/loki/api/v1/push

Alternatively, configure Docker to send logs from all containers by creating an /etc/docker/daemon.json file (again, replace loki-ip with the actual IP of your Loki server):

{
    "debug" : true,
    "log-driver": "loki",
    "log-opts": {
        "loki-url": "http://loki-ip:3100/loki/api/v1/push"
    }
}

After making these changes, recreate your containers to start logging to Loki. With Docker Compose, run the following:

docker-compose down
docker-compose up -d --build

If you chose the daemon.json approach, restart the Docker service:

systemctl restart docker

Loki doesn’t pull logs; instead, Docker pushes logs to Loki. Ensure Docker can reach Loki on port 3100 (if using the default). Test connectivity with telnet from the Docker host:

telnet loki-ip 3100

Step 3: Viewing Logs in Grafana

Now you should be able to see logs in Grafana. Go to the "Explore" section and make sure "Loki" is selected in the top-left dropdown menu.

Then click on "Label Browser" and select the appropriate label. In this example, it’s compose_project => random-logger. Then click "Show logs."

After clicking "Show logs," you should see your logs:

That’s it! At this point, you've successfully set up Grafana with Loki, and your Docker containers should be sending logs to it.

For the next steps, you might consider setting up data retention policies in Loki and creating custom dashboards — I’ll leave that as a homework exercise.

Originally published at Cyberpunk Tools Blog.

How to Create a Widget for Meta Threads using Scriptable

Jurijs Ivolga — Tue, 11 Mar 2025 09:03:56 +0000

I recently started using Meta Threads and saw someone complaining that Meta should create a widget for certain stats. I replied, saying it should be possible using the Scriptable app. Long story short, I decided to dive into this rabbit hole and create some widgets for Meta Threads.

I'll be creating two widgets:

Main widget: Follower counts and profile visitors (today and yesterday)
Secondary widget: View counts for the latest post

We'll use the Scriptable app, which you can download free from the iOS App Store.

Step 1: Set Up the Meta App

Go to Meta for Developers and create an app. The setup process is mostly straightforward ("next-next-next").

Select "I don’t want to connect a business portfolio yet."

Then choose "Access the Threads API".

Enter your app name and email:

Click "Go to Dashboard".

In dashboard settings, continue with more straightforward steps.

First, select permissions under "Access the Threads API"—specifically threads_basic and threads_manage_insights:

Then click "Test Use Cases", followed by "Finish Customization".

Step 2: Add Roles

Navigate to "App Roles" → "Roles".

Click "Add People", select "Threads Tester", and add yourself:

Open the Threads app with your user account, then navigate to Settings → Account → Website Permissions → Invites and accept the invite:

Step 3: Get an Access Token

Visit Facebook Developer Explorer and select "threads.net", then click "Generate Threads Access Token".

Click "Continue" in the pop-up. Your token will appear in the Access Token field.

Validate your token with the Access Token Debugger to ensure it works correctly.

Step 4: Exchange for a Long-Lived Token

Exchange your short-lived token (expires in 60 minutes) for a long-lived token (valid for two months). Follow instructions from Meta Documentation on Long-Lived Tokens using this command:

curl -s -X GET "https://graph.threads.net/access_token?grant_type=th_exchange_token&client_secret=<THREADS_APP_SECRET>&access_token=<SHORT_LIVED_ACCESS_TOKEN>"

To find your THREADS_APP_SECRET, go to your app's settings (App Settings → Basic) on Facebook Apps Dashboard:

Use this secret in the curl command above. Recheck your new long-lived token with the Access Token Debugger.

Step 5: Save Your Long-Lived Token to iCloud

Our scripts will need to access your token and refresh it too. First, we need to store your token in iCloud, so later our scripts can use it. Run this script just once with Scriptable, and later the main widget script will handle future token refreshes automatically.

Token Storage Script (Gist)

Step 6: Building Your Widgets

We'll build two widgets using Scriptable:

A main widget displaying followers count and profile visitors (today/yesterday).
A secondary widget showing view counts of your latest post.

Main Widget Endpoints:

Followers: https://graph.threads.net/v1.0/me/threads_insights?metric=followers_count&access_token=YOUR_TOKEN
Profile Visitors: https://graph.threads.net/v1.0/me/threads_insights?metric=views&access_token=YOUR_TOKEN

Full code:
Main Widget Code (Gist)

Secondary Widget Endpoints:

Fetch latest threads: https://graph.threads.net/v1.0/me/threads?fields=id,text,views&access_token=YOUR_TOKEN
Retrieve stats for latest thread:https://graph.threads.net/v1.0/${postId}/insights?metric=likes,replies,views&access_token=YOUR_TOKEN

Full code:
Secondary Widget Code (Gist)

Originally published at Cyberpunk Tools Blog.

CertDecoder.com - A Free and Simple Online Certificate Decoder"

Jurijs Ivolga — Mon, 10 Mar 2025 16:32:01 +0000

Sometimes in my daily work, I need to handle certificates and double-check their details. Questions like, "Is this a new or old certificate? Does it have the SAN I need?" often come up.

Recently, I decided to build my own online certificate decoder – CertDecoder.com. I know there are dozens, if not hundreds, of certificate decoders available online, but I wanted something simple, fast, and reliable for my own use.

Why try Cert Decoder?

If you're juggling certificates at midnight and struggling to keep your eyes open, you need a straightforward tool to quickly verify your certificate details without extra hassle.

Just open CertDecoder.com, paste your PEM-formatted X.509 certificate, and instantly view its details.

Privacy-first: All processing happens entirely in your browser, ensuring no certificate data is ever leaked.
Retro and minimalist: It's pure HTML—something you rarely see these days, offering a nostalgic, minimalist look.

If you're a web developer, sysadmin, cybersecurity enthusiast, or DevOps junkie, check it out here 👉 CertDecoder.com

I'd greatly appreciate your feedback! 🙏

Feel free to share your suggestions or feature ideas to make it even better.