DEV Community: Nik

AWS SES -> Gmail using Terraform

Nik — Sun, 21 Sep 2025 01:38:54 +0000

The goal

Let's say you have your own domain and you want to have an email address in it, but you don't want to mess with the setup and maintenance of an email server. You also have a working personal email address at Gmail or somewhere else. There is a solution for you.

The architecture

AWS Simple Email Service (SES) is the thing we can leverage to achieve this goal. The basic diagram that represents the solution is here:

So there are a few steps in this solution:

A message is sent to your custom email address
DNS service, AWS Route53 in our case, has an MX entry that points to SES
AWS SES sends this email to S3 bucket
S3 bucket triggers Lambda that reads the message and forwards it to your Gmail address
Once you get this email in your Gmail mailbox you're able to response from your custom email address

The implementation

Since we're using AWS, it makes sense to leverage an IAC approach and write Terraform configuration for all the components involved in this solution. Check here if you want to see the final solution right away.

First of all, make sure you have your bucket for storing your Terraform state set there:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
  backend "s3" {
    bucket = "<put your bucket here>"
    key    = "ses-gmail-custom-domain/terraform.tfstate"
    region = "us-east-1"
  }
}

Then, let's create an SES Identity and DKIM setup:

## SES domain identity
resource "aws_ses_domain_identity" "identity" {
  domain = var.domain_name
}

## SES domain identity DKIM setup
resource "aws_ses_domain_dkim" "dkim" {
  domain = aws_ses_domain_identity.identity.domain
}

Once done, let's verify domain ownership, set MX, DKIM, SPF, DMARC records in Route53:

## SES domain identity -> custom domain verification
resource "aws_route53_record" "amazonses_identity_verification_record" {
  zone_id = data.aws_route53_zone.hosted_zone.id
  name    = "_amazonses.${var.domain_name}"
  type    = "TXT"
  ttl     = "600"
  records = [aws_ses_domain_identity.identity.verification_token]
}

## SES domain identity DKIM entries that allow recipient's mail server to verify digital signature included in email by using a public key stored in these entries
resource "aws_route53_record" "amazonses_identity_dkim_records" {
  for_each = toset(aws_ses_domain_dkim.dkim.dkim_tokens)

  zone_id = data.aws_route53_zone.hosted_zone.id
  name    = "${each.key}._domainkey.${aws_ses_domain_identity.identity.domain}"
  type    = "CNAME"
  ttl     = 600
  records = ["${each.key}.dkim.amazonses.com"]
}

## MX record pointed to SES server
resource "aws_route53_record" "mx_record" {
  zone_id = data.aws_route53_zone.hosted_zone.id
  name    = data.aws_route53_zone.hosted_zone.name
  type    = "MX"
  ttl     = 600
  records = ["10 inbound-smtp.${var.region}.amazonaws.com"]
}

## SPF record that shows that amazonses.com is allowed to send email on behalf of our custom domain
resource "aws_route53_record" "spf_record" {
  zone_id = data.aws_route53_zone.hosted_zone.id
  name    = data.aws_route53_zone.hosted_zone.name
  type    = "TXT"
  ttl     = 600
  records = ["v=spf1 include:amazonses.com -all"]
}

## DMARC record
resource "aws_route53_record" "dmarc_record" {
  zone_id = data.aws_route53_zone.hosted_zone.id
  name    = "_dmarc.${data.aws_route53_zone.hosted_zone.name}"
  type    = "TXT"
  ttl     = 600
  records = ["v=DMARC1; p=none;"]
}

Then, we can create an S3 bucket that will be used to store the emails sent to our custom domain and trigger the lambda funtion to send them:

## S3 bucket for incoming email
resource "aws_s3_bucket" "incoming_email_bucket" {
  bucket = "ses-inbox-${var.author}"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "encryption" {
  bucket = aws_s3_bucket.incoming_email_bucket.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "aws_s3_bucket_notification" "bucket_notification" {
  bucket = aws_s3_bucket.incoming_email_bucket.id

  lambda_function {
    lambda_function_arn = aws_lambda_function.lambda_forwarder.arn
    events              = ["s3:ObjectCreated:*"]
  }

  depends_on = [aws_lambda_permission.s3_bucket_event]
}

Every new email in the bucket will trigger a lambda function that pulls this message from the bucket and sends it to our Gmail account using SES (don't forget about the permissions):

## Lambda email forwarder
data "archive_file" "lambda_zip" {
  output_path = "lambda.zip"
  type        = "zip"
  source_dir  = "lambda-forwarder-source-code"
}

resource "aws_iam_role" "lambda_role" {
  name_prefix        = "ses-email-forwarder-role"
  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}
EOF
}

resource "aws_iam_role_policy" "lambda_policy" {
  name_prefix = "ses-email-forwarder-role-policy"
  policy = jsonencode(
    {
      Version : "2012-10-17",
      Statement : [
        {
          "Effect" : "Allow",
          "Action" : [
            "logs:CreateLogGroup",
            "logs:CreateLogStream",
            "logs:PutLogEvents",
            "logs:DescribeLogStreams"
            ], Resource : [
            "*"
          ]
        },
        {
          "Effect" : "Allow",
          "Action" : [
            "s3:GetObject"
          ],
          "Resource" : [
            "${aws_s3_bucket.incoming_email_bucket.arn}/*"
          ]
        },
        {
          "Effect" : "Allow",
          "Action" : [
            "ses:SendEmail",
            "ses:SendRawEmail"
          ],
          "Resource" : "*"
        }
      ]
  })
  role = aws_iam_role.lambda_role.id
}

resource "aws_lambda_function" "lambda_forwarder" {
  filename         = "lambda.zip"
  function_name    = "ses-email-forwarder"
  role             = aws_iam_role.lambda_role.arn
  handler          = "lambda.lambda_handler"
  source_code_hash = data.archive_file.lambda_zip.output_base64sha256
  runtime          = "python3.9"
  environment {
    variables = {
      REGION     = var.region
      FORWARD_TO = var.original_email
      DOMAIN     = var.domain_name
    }
  }
}

resource "aws_lambda_permission" "s3_bucket_event" {
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.lambda_forwarder.arn
  principal     = "s3.amazonaws.com"
  statement_id  = "event_permissions_from_${aws_s3_bucket.incoming_email_bucket.bucket}"
  source_arn    = aws_s3_bucket.incoming_email_bucket.arn
}

The full Lambda source code could be found in the git repo with some other things like role policies and roles that are being tied to the objects above, not going to go too deep into it here.

So, once the Terraform configuration is applied, the output will contain parameters we need for setting up the Gmail part:

output "ses_smtp_server" {
  value = "email-smtp.${var.region}.amazonaws.com" ## check in your SES -> SMTP settings
}

output "ses_smtp_server_port" {
  value = "587"
}

## SMTP user credentials that would be used on Gmail side to send emails on SES behalf
output "ses_smtp_user_username" {
  value = nonsensitive(aws_iam_access_key.ses_smtp_access_key.id) # just for testing purposes, shouldn't be done in prod
}

output "ses_smtp_user_password" {
  value = nonsensitive(aws_iam_access_key.ses_smtp_access_key.ses_smtp_password_v4) # just for testing purposes, shouldn't be done in prod
}

Having them, we can go to Gmail account settings and create an alias with a new custom domain name.

One important notice about SES Sandbox mode

To be able to send and reply to every email address you will need to jump out of the sandbox mode in SES. To do so, raise a ticket with AWS support and say something like this:

I've set up a custom domain in SES that's being tied to my gmail.com account. So, when someone sends email to my custom email it goes to my gmail.com email. But I can't respond to the recipient from directly, since in the sandbox mode I have to verify the recipient's email first. So, to avoid this limitation, I'd like to jump out of the sandbox mode and be able to reply to anyone who's reaching out to me via my custom email .

Once approved you'll see something like this:

Source code

All the source code could be found here: https://github.com/kolyaiks/ses-gmail-custom-domain
Thank you.

Building a Crypto Portfolio Tracker desktop app with PyQt6

Nik — Sun, 07 Sep 2025 03:12:41 +0000

I’ve been experimenting with the PyQt6 library by building a small pet project: a lightweight Crypto Portfolio Tracker. The idea was to move one of my command-line scripts into a proper desktop app — load a CSV with my holdings, fetch live prices from Kraken, and show everything in a table.

It turned out to be a fun way to explore PyQt6’s layouts, threading, and event handling.

Project Overview

The app provides three main actions:

Load Portfolio – import a CSV file of holdings.
Refresh Prices – fetch current prices from the Kraken API.
Export CSV – save the updated data back to disk.

Along the way, I added multithreading (so the UI stays responsive), a logging system, and a config file for mapping portfolio symbols to Kraken’s trading pairs.

The Core UI

The main window is made up of:

A QTableWidget for portfolio data
Buttons for Load, Refresh, and Export.

def setUI(self):
    self.setWindowTitle("CryptoTracker")

    self.portfolio = pd.DataFrame(columns=["symbol", "amount", "price", "total_value"])

    self.table = QTableWidget()
    self.btn_load = QPushButton("Load Portfolio CSV")
    self.btn_load.clicked.connect(self.load_portfolio)

    self.btn_refresh = QPushButton("Refresh Kraken Prices")
    self.btn_refresh.clicked.connect(self.refresh_prices)

    self.btn_export = QPushButton("Export to CSV")
    self.btn_export.clicked.connect(self.export_csv)

    layout = QVBoxLayout()
    layout.addWidget(self.table)
    layout.addWidget(self.btn_load)
    layout.addWidget(self.btn_refresh)
    layout.addWidget(self.btn_export)

    container = QWidget()
    container.setLayout(layout)
    self.setCentralWidget(container)

Loading the Portfolio

A simple CSV file drives the app. Clicking Load Portfolio opens a file dialog, loads the data into a pandas.DataFrame, and displays it in the table.

def load_portfolio(self):
    file_name, _ = QFileDialog.getOpenFileName(self, "Open CSV", "", "CSV Files (*.csv)")
    if file_name:
        self.portfolio = pd.read_csv(file_name)
        self.logger.info(f"Loaded file {file_name}")
        self.update_table()

Example portfolio.csv:

symbol,amount
BTC,0.05
ETH,0.7
DOGE,1000

Fetching Prices (with Multithreading)

One of the most important lessons in GUI programming: never block the UI thread.
Since calling the Kraken API can take time, I used QThreadPool with a custom Worker class and WorkerSignals class - that's how I pass data from the custom thread to the main one, and update the UI from it while avoiding a Segmentation fault error:

class WorkerSignal(QObject):
    output = pyqtSignal(object)
    error = pyqtSignal(str)

    def __init__(self):
        super().__init__()

class Worker(QRunnable):
    def __init__(self, fn, *args, **kwargs):
        super(Worker, self).__init__()
        self.fn = fn
        self.args = args
        self.kwargs = kwargs
        self.signals = WorkerSignal()

    @pyqtSlot()
    def run(self):
        try:
            result = self.fn(*self.args, **self.kwargs) # Initialising the runner function with passed args, kwargs
            if result:
                self.signals.output.emit((result, *self.args)) # Sends normal result as object (result, kraken_pair, sym)
        except Exception as e:
            self.signals.error.emit(str(e)) # Sends exception to GUI

When the user clicks Refresh Prices, each symbol is processed in a separate worker thread:

    def refresh_prices(self):
        self.logger.debug(f"Refreshing prices")

        if self.portfolio.empty:
            self.logger.error("No data found in portfolio")
            return

        for sym in self.portfolio["symbol"]:
            kraken_pair = self.config['KrakenSymbols'][sym.upper()]
            worker = Worker(self.get_info, kraken_pair, sym)
            worker.signals.output.connect(self.parse_resp)
            worker.signals.error.connect(lambda err: self.logger.error(f"Worker error: {err}")) # quick inline handler for error in worker
            self.threadPool.start(worker)

Example config.ini with Kraken symbol mappings:

[KrakenSymbols]
BTC=XXBTZUSD
ETH=XETHZUSD
DOGE=XDGUSD
USDT=USDTZUSD
SOL=SOLUSD

Updating the Table

After fetching prices, the app updates both the DataFrame and the visible table:

    def update_table(self):
        self.logger.debug(f"Update table {self.table}")

        # Setting up the table based on portfolio file
        self.table.setRowCount(len(self.portfolio))
        self.table.setColumnCount(len(self.portfolio.columns))
        self.table.setHorizontalHeaderLabels(self.portfolio.columns)

        # Updating table rows (used for initial setup and while updating)
        for i, row in self.portfolio.iterrows():
            for j, col in enumerate(self.portfolio.columns):
                self.table.setItem(i, j, QTableWidgetItem(str(row[col])))

Each row then shows:

symbol (e.g., BTC)
amount (from CSV)
price (from Kraken)
total_value (amount × price)

Logging

To keep track of what’s happening, I added a simple logger that writes both to app.log and the console. This was especially helpful when debugging API responses and PyInstaller packaging.

Lessons Learned

Threading is crucial: without it, the UI froze while waiting for Kraken responses.
Thread-safe approach with PyQt means you need to use signals to get data out of a custom worker thread and pass it to the main thread, then update UI from the main thread.
PyQt6 layouts are flexible, but nested layouts take some trial and error.
PyInstaller works, but you need to handle bundled resources like config.ini carefully (sys._MEIPASS trick).
Combining pandas with a QTableWidget makes it easy to keep the GUI and data in sync.
To run the app anywhere as a docker container you can build a docker image from an image with Ubuntu + VNC (for example, accetto/ubuntu-vnc-xfce-g3) and put the app inside it.

Demo and the source code

Here you can find how it looks like: https://youtu.be/YUqXW-J0R_c
The source code could be found here: https://github.com/kolyaiks/crypto_tracker

Deploying SpringBoot application into Kubernetes cluster in AWS using ArgoCD

Nik — Fri, 20 Jun 2025 21:01:03 +0000

In this article I'll walk you through the process of deploying a simple Spring Boot application to a Kubernetes cluster in AWS using GitHub Actions, and Argo CD.
Along the way, we'll also use a few additional tools and components, which we'll briefly cover — though they won't be the main focus of this article.

Why ArgoCD?

ArgoCD nowadays is the industry standard for the K8S deployment process.
Some key benefits:

Declarative GitOps approach
Git is the single source of truth. All deployment configurations are stored in Git, making rollbacks, audits, and version control easy.
Automated Continuous Delivery
Argo CD automates the deployment of applications to Kubernetes once changes are pushed to Git.
Visual UI & Observability
Offers a web UI to visualize:
a. Application status
b. Health of Kubernetes resources
c. Sync status (Git vs cluster)
Access Control & Security
a. Role-based access control (RBAC)
b. Supports integrations with OIDC, SSO providers (e.g., Google, GitHub)
c. Can limit which users can deploy to which namespaces or clusters
Multi-Cluster Support
a. Manages and deploys apps to multiple Kubernetes clusters from a single Argo CD instance
b. Good fit for hybrid or multi-cloud environments
Tooling Flexibility
Supports Helm, Kustomize, Jsonnet, and plain YAML.

Prerequisites

To demonstrate the real-world example we'll need a few things in place before we can jump to the CI/CD process itself.
These things are going be covered by these two repos:

So, the 3 things we need to have before we can go further are:

Kubernetes cluster which has ArgoCD onboard

This is the step where we create all the infrastructure needed for hosting our application - Network, Certificates, DNS entries, and Kubernetes cluster itself. I use Terraform to bootstrap the EKS Kubernetes cluster in AWS, and install ArgoCD into it.
The configuration that covers this part could be found here
Kubernetes YAML configuration
This is the step where we define the K8S components of our application - deployment, service, configmap, ingress.
Since we will have two environments, I use Kustomize here. Kustomize is a Kubernetes-native configuration management tool that allows you to customize raw, template-free base YAML files using overlays, without modifying the original manifests. Overlay will have an environment-specific Spring Boot application properties file that our container application will consume.

The configuration that covers this part could be found here
The application itself
For this demo I created a simple Spring Boot application that renders a simple html page with the environment name and the application version. The environment name is the thing that comes from the Spring Boot properties file.

The repo that covers this part could be found here

Ok, so that was a lot already. I intentionally don't dive too deep into the implementation of each step above since it would be overwhelming, and wouldn't allow us to focus on the main part of this article - the CI/CD part. But if you're curious - feel free to reach out, I'll be glad to speak on details.

CI part

As long as we speak about K8S we need to build the image that will be hosted there.
There are three main components needed to achieve that:

The Dockerfile
That's the thing that uses the multi-stage build approach where the Build stage does the Maven build and the Run stage launches the application.
You can find it here
ECR repository
This image needs to be hosted somewhere. It could be DokerHub, your cloud provider repository, or something else. Because the K8S cluster in my case is placed in AWS, I use ECR service for it.
GitHub Actions CI workflow
This is the part that's responsible for building the docker image from our Dockerfile, pushing it to ECR repository, and setting the updated image in the K8S YAML configuration.
Just as a side note - there are many options to automate CI process. Since the code for this project is being stored in GitHub, I decided to use GitHub Actions. You can use the one you're most comfortable with like Jenkins, or even Argo Workflows.
The code for the GitHub Actions workflow could be found here

CD part

Once the docker image is built and the K8S deployment YAML is updated using the GitHub Actions CI workflow from the application repository, ArgoCD comes into action.
We have an application (ArgoCD entity) in it that constantly monitors the changes in the pre-defined path of the IAC repository related to dev overlay and makes sure the actual cluster state is aligned with the configuration in GitHub. So, once the deployment object gets updated, ArgoCD automatically applies these changes, and no administrator action is needed for the dev environment.

Once the code is synced you can open dev-app.put-your-domain-here.com in your browser and see the application environment and version like this:

But do we want to see the same behavior for the prod? Probably, not. That's why use the second workflow placed in the IAC repo here:
That's the workflow that gets an image version as an input and raises the PR to the main branch of IAC repo with the updated image version for the prod overlay. Once the PR is raised, the administrator reviews and approves it. So, the thing that's needed to see these changes in production is to press the SYNC button in the ArgoCD UI.

Once the code is synced you can open prod-app.put-your-domain-here.com in your browser and see the application environment and version like this:

Conclusion

That’s it — we’ve fully automated the CI/CD pipeline for deploying the SpringBoot application to the Kubernetes cluster, using Terraform to spin up the infrastructure in AWS, GitHub Actions for continuous integration, and Argo CD for continuous delivery.
Now, every development build is deployed automatically without manual intervention, while production releases require a pull request review and merge.

Feel free to ask questions, share your experience and suggestions in the comments section below.
Cheers!

The video version of this article could be found here: https://youtu.be/PxBy87_MxWU