{
  "id": 8788169,
  "title": "Automating Deployment with Github Actions",
  "url": "https://urgent.news/2026/09/20/automating-deployment-with-github-actions",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-20T22:49:56.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/israeltheory/automating-deployment-with-github-actions-24i1"
  },
  "original_language": "en",
  "account": "Tackling the Challenge of Deploying to a Private Subnet Server\n\nIn the world of continuous integration and continuous deployment (CI/CD), automating the deployment process has become a necessity for modern software development. However, when your server resides in a private subnet, behind a load balancer, and is unreachable via the internet, the task becomes more complex. The traditional approach of SSHing into the server and pulling the Docker image for deployment is not viable in this scenario.\n\nThe first obstacle is the server's isolation within a private subnet (10.0.10.0/24), which excludes direct internet access. GitHub Actions, the popular CI/CD platform, utilizes SSH to interact with servers, but it cannot reach the target EC2 instance. Furthermore, there is no public IP address assigned to the server, nor is there an open port 22 for SSH connections. Additionally, there is no bastion host configured to facilitate remote access.\n\nThe second challenge lies in the complexity of the deployment itself. Instead of a single Docker image, the deployment involves a docker-compose.yml configuration managing four interdependent services. These services include PostgreSQL, Backend, Frontend, and Nginx. Each service must be deployed in a specific order, with health checks ensuring that dependencies are satisfied before proceeding. If any service fails to start correctly, it can lead to cascading failures and errors.\n\nTo overcome these hurdles, the solution relies on three AWS services that were already set up in the infrastructure: IAM OIDC (Identity and Access Management with OpenID Connect), Systems Manager (SSM), and Terraform. This approach eliminates the need for stored AWS credentials, enhances security, and enables the orchestration of the multi-container stack.\n\nThe deployment pipeline operates as follows:\n\n1. Upon a push to the main branch or a pull request, the GitHub Actions CI workflow is triggered.\n2. The CI workflow performs several crucial tasks:\n- It checks out the code using the actions/checkout action.\n- Docker Compose is utilized to build all four container images, ensuring that any build errors are caught early.\n- The frontend is built using Vite, React, and Node.js. If there are any TypeScript errors or import issues, the build will fail, preventing further progress.\n- The backend is linted using Flake8, a Python linting tool. The linting process catches syntax errors and style violations, ensuring the code quality meets the desired standards.\n3. If all checks pass, the CI workflow transitions to the CD (Continuous Delivery) workflow.\n4. The CD workflow initiates by requesting an OIDC token from GitHub's token service. This token serves as a secure means of authentication and authorization.\n5. With the OIDC token, the CD workflow presents it to AWS STS (Security Token Service). STS issues temporary credentials valid for one hour, enabling the pipeline to interact with AWS services.\n6. The temporary credentials obtained from STS are utilized to send an SSM (Systems Manager) command to the EC2 instance residing in the private subnet.\n7. The EC2 instance executes a deploy.sh script, which performs the necessary steps to pull the updated Docker images, start the services, and ensure their health and interdependencies are satisfied.\n8. Finally, the logs are fetched, and the success or failure of the deployment is verified.\n\nBy leveraging IAM OIDC, SSM, and Terraform, the deployment process becomes keyless, secure, and scalable. The only secret stored in GitHub Secrets is the ARN (Amazon Resource Name) of an IAM role, which acts as a reference rather than an actual credential. This approach eliminates the risk of leaked credentials being valid for extended periods and ensures better control over access to the server.\n\nIn summary, deploying to a server situated in a private subnet poses unique challenges in the realm of CI/CD. However, by utilizing AWS services such as IAM OIDC, SSM, and Terraform, it is possible to automate the deployment process effectively. By incorporating checks, linting, and orchestration of the multi-container stack, the deployment pipeline ensures that the code is thoroughly validated before being deployed to the server. This approach not only enhances security but also streamlines the development lifecycle, enabling faster and more reliable software delivery.",
  "summary": "The article discusses the challenges of automating deployment to a server that is unreachable from the internet due to its location in a private subnet behind a load balancer. The author highlights three main problems: the server's unreachability, the complexity of deploying a multi-container stack using Docker Compose, and the need for keyless authentication. To overcome these obstacles, the author proposes using GitHub Actions in conjunction with AWS Systems Manager (SSM) and OpenID Connect (OIDC) to create a CI/CD pipeline that builds, tests, and deploys the application automatically. This solution eliminates the need for stored AWS credentials, maintains security by avoiding leaked keys, and enables the orchestration of a complex multi-container stack.",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}