Your data is already there. Your database is already breathing. But your back office is still buried under weeks of repetitive work.

AdminForth breaks the cage.

It lets you build secure, powerful, agent-ready admin panels on top of your existing database without surrendering your code, your architecture, or your freedom to a closed SaaS.

Not a rented dashboard. Not another CRUD graveyard. Not a black box between you and your data.

Your back office. Your rules. Your agents.

This guide shows how to deploy own Docker apps (with AdminForth as example) to Amazon EC2 instance with K3s and Terraform involving pushing images into Amazon ECR.

Needed resources:

• AWS account where we will auto-spawn EC2 instance. We will use t3a.small instance (2 vCPUs, 2GB RAM) which costs ~14$ per month in us-west-2 region (cheapest region). Also it will take $2 per month for EBS gp2 storage (20GB) for EC2 instance.
• Also AWS ECR will charge for $0.09 per GB of data egress traffic (from EC2 to the internet) - this needed to load docker build cache.

The setup shape:

• Build is done using IaaC approach with HashiCorp Terraform, so almoast no manual actions are needed from you. Every resource including EC2 server instance is described in code which is commited to repo.
• Docker images and build cache are stored on Amazon ECR
• Total build time for average commit to AdminForth app (with Vite rebuilds) is around 3 minutes.

This guide shows how you can set up Context7 MCP in your Visual Studio Code IDE (VS Code)

When you are using AdminForth i18n plugin for external Apps translation you might face a case when you need to translate some data stored in your database which potentially can be changed in future.

Keycloak is an open-source identity and access management solution that provides authentication and authorization services. It can be used to secure applications and services by managing user identities, roles, and permissions.

In this guide, we will walk you through the process of setting up AdminForth authorization via Keycloak. Most important we will show you how to set up Keycloak in a Docker container and configure it to work with AdminForth.

This guide shows how to deploy own Docker apps (with AdminForth as example) to Amazon EC2 instance with Docker and Terraform involving pushing images into Amazon ECR.

Needed resources:

• GitHub actions Free plan which includes 2000 minutes per month (1000 of 2-minute builds per month - more then enough for many projects, if you are not running tests). Extra builds would cost 0.008$ per minute.
• AWS account where we will auto-spawn EC2 instance. We will use t3a.small instance (2 vCPUs, 2GB RAM) which costs ~14$ per month in us-east-1 region (cheapest region). Also it will take $2 per month for EBS gp2 storage (20GB) for EC2 instance.
• Also AWS ECR will charge for $0.09 per GB of data egress traffic (from EC2 to the internet) - this needed to load docker build cache.

The setup shape:

• Build is done using IaaC approach with HashiCorp Terraform, so almoast no manual actions are needed from you. Every resource including EC2 server instance is described in code which is commited to repo.
• Docker build process is done on GitHub actions server, so EC2 server is not overloaded with builds
• Changes in infrastructure including changing server type, adding S3 Bucket, changing size of sever disk is also can be done by commiting code to repo.
• Docker images and build cache are stored on Amazon ECR
• Total build time for average commit to AdminForth app (with Vite rebuilds) is around 2 minutes.

This guide is a hackers extended addition of Deploying AdminForth to EC2 with Amazon ECR. The key difference in this post that we will not use Amazon ECR but self-host registry on EC2 itself. Automatically from terraform. And will see whether we will win something in terms of build time.

Our framework has a CI pipeline that runs npm run build, publishes the package to NPM (npm publish), and creates a new release on GitHub. It also sends a notification about the release to a Slack webhook for our team.

Secrets for these services were stored in our CI’s built-in Vault (we are running a self-hosted Woodpecker CI).

Recently, while moving plugins to separate repositories, I decided to try Infisical for centralized secrets management instead of the internal CI Vault. Infisical provides a self-hosted open-source solution, has a well-organized UI, and offers better access control than our CI Vault. It was important to me that I could reuse secrets across different repositories without copying them every time I created a new plugin.

Here’s what I did:

I have a feeling that after first ~600 versions of Adminforth we faced all possible issues with manual versioning and release notes.

Manual versioning and CHANGELOG.md is unreliable as human beings are. It is pretty easy to forget it with relevant information, forget to include some changes, forget to push it to GitHub, push it at wrong time, and many more things.

That is why we decided to move the idea of generating versions, and GitHub releases from git commit messages using great tool called semantic-release.

In this post I will explain why we did a transition from manual releases to automatic, what profits we got from it, and also will show you simple example how to do it in your project!

Every reliable system requires a backup strategy.

If you have no own backup infrastructure, here can suggest a small docker container that will help you to backup your database to AWS Glacier.