DEV Community: Rishi Vachhani

How to Automatically Replicate AWS SSM Parameters Across Regions Using EventBridge and Lambda

Rishi Vachhani — Sun, 21 Jun 2026 12:15:24 +0000

AWS Systems Manager Parameter Store is regional by design.

If you create a parameter in ap-south-1, it doesn't automatically exist in us-east-1.

For teams running disaster recovery environments, active-passive architectures, or multi-region applications, maintaining identical configuration across regions quickly becomes an operational challenge.

In this guide, we'll build a fully serverless solution that automatically replicates SSM parameters whenever they are created, updated, or deleted.

The solution uses:

AWS Systems Manager Parameter Store
AWS CloudTrail
Amazon EventBridge
AWS Lambda
Python (boto3)

The end result is a low-cost, event-driven synchronization mechanism that keeps regions aligned automatically.

Why I Built This

While working on a disaster recovery setup recently, I noticed something that often gets overlooked.

Infrastructure was deployed in multiple regions.

Application containers were deployed.

Databases were replicated.

Monitoring was configured.

Everything looked good.

Until we started validating failover.

Several services immediately failed because critical SSM parameters only existed in the primary region.

Things like:

/prod/app/DB_PASSWORD
/prod/app/API_KEY
/prod/api/JWT_SECRET

were missing in the secondary region.

AWS Parameter Store is regional, which means your applications only see parameters that exist within the region they're running in.

The obvious solution is manually maintaining copies.

The practical solution is automating synchronization.

Architecture Overview

Whenever someone creates, updates, or deletes a parameter:

CloudTrail records the API call.
EventBridge captures the event.
Lambda is invoked.
Lambda determines the operation type.
Lambda replicates the change to one or more destination regions.

Create / Update / Delete Parameter
                │
                ▼
           CloudTrail
                │
                ▼
           EventBridge
                │
                ▼
              Lambda
                │
                ▼
      Destination Region(s)

No servers.

No polling.

No scheduled jobs.

No manual intervention.

Why Replicate Deletes?

In many organizations, disaster recovery environments are expected to mirror production as closely as possible.

If a parameter is intentionally removed from the source region, keeping it in destination regions can introduce configuration drift.

By replicating delete operations as well:

Regions remain fully synchronized
Stale parameters are automatically removed
Configuration remains consistent across environments
Operational overhead is reduced

⚠️ Production Note:

If accidental deletions are a concern in your organization, consider removing delete replication and handling deletions manually through change management processes.

Prerequisites

Before getting started, ensure you have:

AWS CLI configured
Python 3.10+
boto3 installed
CloudTrail enabled
Lambda execution role with SSM permissions

Install boto3:

pip install boto3

Step 1 - Enable CloudTrail

EventBridge receives SSM API activity through CloudTrail.

Without CloudTrail, EventBridge never sees Parameter Store changes.

Navigate to:

AWS Console
→ CloudTrail
→ Trails
→ Create Trail

Recommended settings:

Management Events : Enabled
API Activity      : Write
CloudWatch Logs   : Enabled

Once enabled, CloudTrail begins recording Parameter Store API calls.

Step 2 - Create the EventBridge Rule

Navigate to:

AWS Console
→ EventBridge
→ Rules
→ Create Rule

Use the following event pattern:

{
  "source": ["aws.ssm"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ssm.amazonaws.com"],
    "eventName": [
      "PutParameter",
      "DeleteParameter",
      "DeleteParameters"
    ]
  }
}

This ensures that parameter creations, updates, and deletions trigger the replication Lambda.

Step 3 - Deploy the Lambda Replicator

Environment Variables

Variable	Description	Example
DEST_REGIONS	Destination AWS regions	us-east-1,eu-west-1
PARAM_PATHS	Parameter paths to replicate	/prod/app,/prod/api
DEST_KMS_KEY_ID	KMS key for SecureString parameters	alias/prod-key
DRY_RUN	Preview mode without writes	false

Example Configuration

DEST_REGIONS=us-east-1,eu-west-1
PARAM_PATHS=/prod/app,/prod/api
DEST_KMS_KEY_ID=alias/prod-key
DRY_RUN=false

Lambda Function

The Lambda performs the following actions:

Receives EventBridge events
Extracts parameter names
Determines create, update, or delete operations
Validates watched paths
Reads source parameter values
Replicates values and tags
Deletes parameters in destination regions when required
Produces structured CloudWatch logs

Supported Features

PutParameter
DeleteParameter
DeleteParameters
Native Parameter Store Change Events
Multiple destination regions
SecureString replication
Tag replication
Dry-run mode

"""
SSM Parameter Store Cross-Region Replicator
============================================
Triggered by: EventBridge rule watching SSM Parameter Store events in source region
              (PutParameter, DeleteParameter)

Environment Variables (set in Lambda config):
  DEST_REGIONS      : Comma-separated destination regions  e.g. "us-east-1,eu-west-1"
  PARAM_PATHS       : Comma-separated path prefixes to watch e.g. "/prod/app,/prod/api"
  DEST_PARAM_TYPE   : (Optional) Force a type — String | SecureString | StringList
                      Default: preserves the source parameter's original type
  DEST_KMS_KEY_ID   : (Optional) KMS Key ID/ARN to use in destination for SecureString
                      Default: uses AWS managed key (alias/aws/ssm)
  DRY_RUN           : (Optional) Set to "true" to log actions without writing. Default: false

IAM permissions required on Lambda execution role:
  Source region:
    ssm:GetParameter
    ssm:GetParametersByPath
    ssm:DescribeParameters

  Destination region(s):
    ssm:PutParameter
    ssm:DeleteParameter
    ssm:AddTagsToResource

  KMS (if using SecureString with custom key):
    kms:GenerateDataKey
    kms:Decrypt
"""

import boto3
import json
import logging
import os
import re
from botocore.exceptions import ClientError, BotoCoreError

# ── Logging ──────────────────────────────────────────────────────────────────
logger = logging.getLogger()
logger.setLevel(logging.INFO)

def log_info(msg, **kwargs):
    logger.info(json.dumps({"level": "INFO", "message": msg, **kwargs}))

def log_warn(msg, **kwargs):
    logger.warning(json.dumps({"level": "WARN", "message": msg, **kwargs}))

def log_error(msg, **kwargs):
    logger.error(json.dumps({"level": "ERROR", "message": msg, **kwargs}))


# ── Config ───────────────────────────────────────────────────────────────────

class Config:
    """Reads and validates all environment variables at cold-start."""

    def __init__(self):
        self.dest_regions   = self._parse_list("DEST_REGIONS")
        self.param_paths    = self._parse_list("PARAM_PATHS")
        self.dest_param_type = os.environ.get("DEST_PARAM_TYPE", "").strip() or None
        self.dest_kms_key   = os.environ.get("DEST_KMS_KEY_ID", "").strip() or None
        self.dry_run        = os.environ.get("DRY_RUN", "false").strip().lower() == "true"
        self._validate()

    def _parse_list(self, env_var):
        raw = os.environ.get(env_var, "").strip()
        if not raw:
            raise EnvironmentError(f"Required environment variable '{env_var}' is not set or empty.")
        return [item.strip() for item in raw.split(",") if item.strip()]

    def _validate(self):
        valid_regions_pattern = re.compile(r'^[a-z]{2}-[a-z]+-\d+$')
        for region in self.dest_regions:
            if not valid_regions_pattern.match(region):
                raise ValueError(f"Invalid region format: '{region}'. Expected format like 'us-east-1'.")

        for path in self.param_paths:
            if not path.startswith("/"):
                raise ValueError(f"PARAM_PATHS entry '{path}' must start with '/'. e.g. '/prod/app'")

        valid_types = {"String", "StringList", "SecureString"}
        if self.dest_param_type and self.dest_param_type not in valid_types:
            raise ValueError(f"DEST_PARAM_TYPE '{self.dest_param_type}' is invalid. Choose from: {valid_types}")

        if self.dry_run:
            log_warn("DRY_RUN is enabled — no parameters will be written.")

        log_info("Configuration loaded",
                 dest_regions=self.dest_regions,
                 param_paths=self.param_paths,
                 dest_param_type=self.dest_param_type or "preserve-source",
                 dest_kms_key=self.dest_kms_key or "aws-managed-default",
                 dry_run=self.dry_run)


# Load config once at cold-start so errors surface immediately in CloudWatch
try:
    CONFIG = Config()
except (EnvironmentError, ValueError) as e:
    log_error("Configuration error — Lambda will not process events until fixed.", error=str(e))
    CONFIG = None


# ── Helpers ──────────────────────────────────────────────────────────────────

def normalize_path(path: str) -> str:
    """Ensure path starts with / and has no trailing slash."""
    path = path.strip()
    if not path.startswith("/"):
        path = "/" + path
    return path.rstrip("/")


def path_is_watched(param_name: str, watched_paths: list) -> bool:
    """Return True if param_name is under one of the watched path prefixes."""
    for prefix in watched_paths:
        if param_name == prefix or param_name.startswith(prefix + "/"):
            return True
    return False


def get_source_parameter(ssm_source, param_name: str) -> dict | None:
    """
    Fetch the current value + metadata of a parameter from the source region.
    Returns None if the parameter does not exist (e.g. was deleted).
    """
    try:
        response = ssm_source.get_parameter(Name=param_name, WithDecryption=True)
        param = response["Parameter"]
        log_info("Fetched source parameter",
                 name=param_name,
                 type=param.get("Type"),
                 version=param.get("Version"))
        return param
    except ClientError as e:
        code = e.response["Error"]["Code"]
        if code == "ParameterNotFound":
            log_warn("Parameter not found in source region — may have been deleted.", name=param_name)
            return None
        log_error("Failed to fetch source parameter",
                  name=param_name,
                  error_code=code,
                  error=str(e))
        raise


def get_parameter_tags(ssm_source, param_name: str) -> list:
    """Fetch tags from the source parameter. Returns empty list on failure."""
    try:
        response = ssm_source.list_tags_for_resource(
            ResourceType="Parameter",
            ResourceId=param_name
        )
        return response.get("TagList", [])
    except ClientError as e:
        log_warn("Could not fetch tags for parameter — tags will not be replicated.",
                 name=param_name,
                 error=str(e))
        return []


def replicate_put(ssm_dest, dest_region: str, param: dict, tags: list, config: Config):
    """Write a parameter to the destination region."""
    name  = param["Name"]
    value = param["Value"]
    ptype = config.dest_param_type or param.get("Type", "SecureString")
    desc  = param.get("Description", "Replicated by SSM cross-region replicator Lambda")

    put_kwargs = dict(
        Name=name,
        Value=value,
        Type=ptype,
        Description=desc,
        Overwrite=True,
        Tier="Standard",
    )

    if ptype == "SecureString" and config.dest_kms_key:
        put_kwargs["KeyId"] = config.dest_kms_key

    log_info("Replicating parameter",
             action="PUT",
             name=name,
             dest_region=dest_region,
             type=ptype,
             dry_run=config.dry_run)

    if config.dry_run:
        return

    try:
        response = ssm_dest.put_parameter(**put_kwargs)
        log_info("Parameter replicated successfully",
                 name=name,
                 dest_region=dest_region,
                 version=response.get("Version"))

        # Replicate tags if any
        if tags:
            ssm_dest.add_tags_to_resource(
                ResourceType="Parameter",
                ResourceId=name,
                Tags=tags
            )
            log_info("Tags replicated", name=name, dest_region=dest_region, tag_count=len(tags))

    except ClientError as e:
        log_error("Failed to replicate parameter",
                  name=name,
                  dest_region=dest_region,
                  error_code=e.response["Error"]["Code"],
                  error=str(e))
        raise


def replicate_delete(ssm_dest, dest_region: str, param_name: str, config: Config):
    """Delete a parameter in the destination region."""
    log_info("Replicating delete",
             action="DELETE",
             name=param_name,
             dest_region=dest_region,
             dry_run=config.dry_run)

    if config.dry_run:
        return

    try:
        ssm_dest.delete_parameter(Name=param_name)
        log_info("Parameter deleted successfully",
                 name=param_name,
                 dest_region=dest_region)
    except ClientError as e:
        code = e.response["Error"]["Code"]
        if code == "ParameterNotFound":
            log_warn("Parameter already absent in destination region — nothing to delete.",
                     name=param_name,
                     dest_region=dest_region)
            return
        log_error("Failed to delete parameter",
                  name=param_name,
                  dest_region=dest_region,
                  error_code=code,
                  error=str(e))
        raise


def parse_event(event: dict) -> tuple[str, list, str]:
    """
    Extract (action, param_names, source_region) from the EventBridge event.

    param_names is always a list — most events carry a single parameter,
    but the console's "Delete" button (and any batch delete) calls the
    DeleteParameters (plural) API, which can carry multiple names in one
    CloudTrail event.

    Supported event sources:
      - EventBridge + CloudTrail: detail-type = "AWS API Call via CloudTrail"
      - EventBridge native SSM events: detail-type = "Parameter Store Change"
    """
    detail      = event.get("detail", {})
    detail_type = event.get("detail-type", "")
    source_region = event.get("region", os.environ.get("AWS_REGION", ""))

    # ── CloudTrail-based event ────────────────────────────────────────────────
    if detail_type == "AWS API Call via CloudTrail":
        event_name = detail.get("eventName", "")
        request_params = detail.get("requestParameters", {}) or {}

        action_map = {
            "PutParameter"     : "PUT",
            "DeleteParameter"  : "DELETE",
            "DeleteParameters" : "DELETE",
        }
        action = action_map.get(event_name)
        if not action:
            raise ValueError(f"Unsupported or ignored CloudTrail eventName: '{event_name}'")

        if event_name == "DeleteParameters":
            # Batch delete — names come back as a list
            raw_names = request_params.get("names") or request_params.get("Names") or []
            if not raw_names:
                raise ValueError(f"Could not extract parameter names from CloudTrail event: {json.dumps(detail)}")
            param_names = [normalize_path(n) for n in raw_names]
        else:
            # Single put/delete — name comes back as a string
            raw_name = request_params.get("name") or request_params.get("Name") or ""
            if not raw_name:
                raise ValueError(f"Could not extract parameter name from CloudTrail event: {json.dumps(detail)}")
            param_names = [normalize_path(raw_name)]

        return action, param_names, source_region

    # ── Native SSM EventBridge event ──────────────────────────────────────────
    if detail_type == "Parameter Store Change":
        operation = detail.get("operation", "")
        param_name = detail.get("name", "")

        if not param_name:
            raise ValueError(f"Could not extract parameter name from SSM event: {json.dumps(detail)}")

        action_map = {
            "Create" : "PUT",
            "Update" : "PUT",
            "Delete" : "DELETE",
            "LabelParameterVersion": None,  # Ignored
        }
        action = action_map.get(operation)
        if action is None:
            raise ValueError(f"Unsupported or ignored SSM operation: '{operation}'")

        return action, [normalize_path(param_name)], source_region

    raise ValueError(f"Unsupported event detail-type: '{detail_type}'. "
                     f"Expected 'AWS API Call via CloudTrail' or 'Parameter Store Change'.")


# ── Lambda Handler ────────────────────────────────────────────────────────────

def lambda_handler(event, context):
    log_info("Lambda invoked",
             request_id=context.aws_request_id,
             function=context.function_name,
             remaining_ms=context.get_remaining_time_in_millis())

    # Config failed at cold-start — abort early with a clear message
    if CONFIG is None:
        log_error("Aborting: Lambda has invalid configuration. Fix environment variables and redeploy.")
        return {"statusCode": 500, "body": "Invalid Lambda configuration — check CloudWatch logs."}

    # ── Parse the incoming event ──────────────────────────────────────────────
    try:
        action, param_names, source_region = parse_event(event)
    except ValueError as e:
        log_error("Event parsing failed — skipping.", error=str(e), raw_event=json.dumps(event))
        return {"statusCode": 400, "body": str(e)}

    log_info("Event parsed",
             action=action,
             param_names=param_names,
             source_region=source_region)

    # ── Filter down to only the parameters under a watched path ────────────────
    watched_param_names = [p for p in param_names if path_is_watched(p, CONFIG.param_paths)]
    skipped_param_names = [p for p in param_names if p not in watched_param_names]

    if skipped_param_names:
        log_info("Some parameters are not under a watched path — skipping them.",
                 skipped=skipped_param_names,
                 watched_paths=CONFIG.param_paths)

    if not watched_param_names:
        log_info("No parameters in this event are under a watched path — skipping.",
                 param_names=param_names,
                 watched_paths=CONFIG.param_paths)
        return {"statusCode": 200, "body": "No parameters in watched paths — skipped."}

    # ── Source SSM client ─────────────────────────────────────────────────────
    ssm_source = boto3.client("ssm", region_name=source_region)

    all_results = {}

    for param_name in watched_param_names:
        results = {}

        # ── Replicate to each destination region ──────────────────────────────
        for dest_region in CONFIG.dest_regions:

            if dest_region == source_region:
                log_warn("Destination region is the same as source — skipping to avoid overwrite.",
                         region=dest_region)
                results[dest_region] = "skipped-same-region"
                continue

            ssm_dest = boto3.client("ssm", region_name=dest_region)

            try:
                if action == "DELETE":
                    replicate_delete(ssm_dest, dest_region, param_name, CONFIG)
                    results[dest_region] = "deleted"
                    continue

                # Fetch latest value from source
                param = get_source_parameter(ssm_source, param_name)
                if param is None:
                    log_warn("Source parameter vanished before replication — skipping.",
                             name=param_name,
                             dest_region=dest_region)
                    results[dest_region] = "skipped-source-not-found"
                    continue

                tags = get_parameter_tags(ssm_source, param_name)
                replicate_put(ssm_dest, dest_region, param, tags, CONFIG)
                results[dest_region] = "replicated"

            except (ClientError, BotoCoreError) as e:
                log_error("Replication failed for destination region",
                          dest_region=dest_region,
                          param_name=param_name,
                          error=str(e))
                results[dest_region] = f"error: {str(e)}"

        all_results[param_name] = results

    log_info("Replication complete", action=action, results=all_results)

    return {
        "statusCode": 200,
        "body": json.dumps({
            "action": action,
            "results": all_results
        })
    }

IAM Permissions

The Lambda execution role requires the following permissions.

Source Region

{
  "Effect": "Allow",
  "Action": [
    "ssm:GetParameter",
    "ssm:GetParametersByPath",
    "ssm:DescribeParameters",
    "ssm:ListTagsForResource"
  ],
  "Resource": "*"
}

Destination Regions

{
  "Effect": "Allow",
  "Action": [
    "ssm:PutParameter",
    "ssm:DeleteParameter",
    "ssm:AddTagsToResource"
  ],
  "Resource": "*"
}

If SecureString parameters use a customer-managed KMS key:

{
  "Effect": "Allow",
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

Step 4 - Bulk Sync Existing Parameters

The Lambda only handles future changes.

What about parameters that already exist?

For that we use a one-time bulk synchronization script.

This script:

Reads all parameters under configured prefixes
Preserves parameter values
Preserves SecureString encryption
Preserves descriptions
Preserves tags
Writes everything to the destination region

Preview Before Writing

Always start with a dry run.

DRY_RUN=true \
SOURCE_REGION=ap-south-1 \
DESTINATION_REGION=us-east-1 \
PARAMETER_PREFIXES=/prod/app,/prod/api \
python bulk_sync_ssm.py

Example output:

[DRY-RUN] Would write → /prod/app/DB_HOST
[DRY-RUN] Would write → /prod/app/DB_PASSWORD
[DRY-RUN] Would write → /prod/api/JWT_SECRET

No parameters are modified.

Execute the Synchronization

Once satisfied:

SOURCE_REGION=ap-south-1 \
DESTINATION_REGION=us-east-1 \
PARAMETER_PREFIXES=/prod/app,/prod/api \
python bulk_sync_ssm.py

Example output:

[OK] /prod/app/DB_HOST
[OK] /prod/app/DB_PASSWORD
[OK] /prod/api/JWT_SECRET

Testing the Setup

Test Parameter Creation

aws ssm put-parameter \
  --name "/prod/app/DB_HOST" \
  --value "database.example.com" \
  --type String \
  --overwrite \
  --region ap-south-1

Verify:

aws ssm get-parameter \
  --name "/prod/app/DB_HOST" \
  --region us-east-1

Test Parameter Update

aws ssm put-parameter \
  --name "/prod/app/DB_HOST" \
  --value "new-database.example.com" \
  --type String \
  --overwrite \
  --region ap-south-1

Verify the updated value exists in the destination region.

Test Parameter Deletion

aws ssm delete-parameter \
  --name "/prod/app/DB_HOST" \
  --region ap-south-1

Verify:

aws ssm get-parameter \
  --name "/prod/app/DB_HOST" \
  --region us-east-1

Expected result:

ParameterNotFound

Common Issues

Lambda Never Triggers

Usually caused by:

CloudTrail disabled
EventBridge rule in the wrong region

AccessDeniedException

Ensure the Lambda role has:

ssm:GetParameter
ssm:GetParametersByPath
ssm:DescribeParameters
ssm:PutParameter
ssm:DeleteParameter
ssm:AddTagsToResource

InvalidKeyId

The destination KMS key does not exist.

Either:

Create the key
Use AWS-managed encryption

Parameters Not Replicating

Verify the parameter path matches one of the configured prefixes:

/prod/app
/prod/api

Security Recommendations

Use SecureString

Encrypt sensitive values:

Database passwords
API keys
Access tokens
JWT secrets

Restrict IAM Permissions

Avoid:

ssm:* on *

Instead:

arn:aws:ssm:*:*:parameter/prod/*

Enable Monitoring

Monitor:

Lambda errors
Replication failures
Unexpected Parameter Store changes

Operational visibility becomes invaluable when troubleshooting.

Cost Considerations

This solution is surprisingly inexpensive.

You're only using:

EventBridge
Lambda
CloudTrail
Parameter Store

There are no always-running resources.

For most teams, the monthly cost is negligible compared to the operational effort saved.

Complete Workflow

Day 0
│
├─ Enable CloudTrail
├─ Deploy Lambda
├─ Create EventBridge Rule
├─ Run bulk_sync_ssm.py
└─ Verify replication

Day 1+
│
├─ Developer creates parameter
│     └─ Replicated
│
├─ Developer updates parameter
│     └─ Replicated
│
├─ Developer deletes parameter
│     └─ Deleted from destination regions
│
└─ Regions remain synchronized automatically

Final Thoughts

AWS doesn't currently provide native cross-region replication for Parameter Store.

Fortunately, combining CloudTrail, EventBridge, and Lambda makes it easy to build your own event-driven synchronization mechanism.

The biggest lesson from implementing this in production is that configuration drift is rarely caused by technology—it is usually caused by manual processes.

By automating parameter replication for creates, updates, and deletions, you remove an entire category of operational risk and ensure that all regions remain synchronized automatically.

If you're running multi-region AWS workloads, this is one of those small automations that quietly saves hours of troubleshooting later.

Happy building 🚀

Acknowledgements

A special thanks to *@vikram_patel * for collaboration, testing, and valuable feedback during the implementation of this solution.

Streamline Your Flutter Development: Complete CI/CD Pipeline with GitHub Actions and Google Play Store Deployment

Rishi Vachhani — Sat, 30 Aug 2025 11:13:44 +0000

Streamline Your Flutter Development: Complete CI/CD Pipeline with GitHub Actions and Google Play Store Deployment

As Flutter applications grow in complexity, manual building and deployment processes become time-consuming and error-prone. Implementing a robust CI/CD (Continuous Integration/Continuous Deployment) pipeline can dramatically improve your development workflow, reduce human errors, and ensure consistent releases.

In this comprehensive guide, we'll walk through setting up an automated CI/CD pipeline using GitHub Actions that builds your Flutter app, runs tests, and deploys directly to the Google Play Store.

What You'll Learn

Setting up GitHub Actions for Flutter CI/CD
Configuring automatic deployment to Google Play Store
Best practices for managing secrets and sensitive data
Real-world pipeline configuration with practical examples
Common pitfalls and how to avoid them

Prerequisites

Before we dive in, ensure you have:

A Flutter application hosted on GitHub
A Google Play Console developer account
Basic understanding of YAML and GitHub Actions
Android app signing key (we'll cover this)

Part 1: Understanding the CI/CD Pipeline

Our pipeline will consist of three main stages:

Continuous Integration (CI): Code validation, testing, and building
Continuous Deployment (CD): Automated deployment to Google Play Store
Monitoring: Pipeline health and deployment status tracking

Part 2: Setting Up Google Play Console

Step 1: Create a Service Account

Visit the Google Cloud Console
Create a new project or select an existing one
Navigate to "IAM & Admin" → "Service Accounts"
Click "Create Service Account"
Fill in the service account details:
- Name: flutter-ci-cd-service
- Description: Service account for Flutter CI/CD pipeline

Step 2: Configure Play Console Access

Go to Google Play Console
Navigate to "Setup" → "API access"
Link your Google Cloud project
Grant access to your service account with these permissions:
- Release manager: For uploading and releasing apps
- View app information: For reading app metadata

Step 3: Generate Service Account Key

In Google Cloud Console, go to your service account
Click "Keys" → "Add Key" → "Create new key"
Select "JSON" format
Download the key file (keep it secure!)

Part 3: Android App Signing Setup

Generate Upload Key

keytool -genkey -v -keystore upload-keystore.jks -keyalg RSA -keysize 2048 -validity 10000 -alias upload

Create key.properties

Create android/key.properties:

storePassword=your_keystore_password
keyPassword=your_key_password
keyAlias=upload
storeFile=upload-keystore.jks

Configure build.gradle

Update android/app/build.gradle:

// Add before android block
def keystoreProperties = new Properties()
def keystorePropertiesFile = rootProject.file('key.properties')
if (keystorePropertiesFile.exists()) {
    keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
}

android {
    // ... existing configuration

    signingConfigs {
        release {
            keyAlias keystoreProperties['keyAlias']
            keyPassword keystoreProperties['keyPassword']
            storeFile keystoreProperties['storeFile'] ? file(keystoreProperties['storeFile']) : null
            storePassword keystoreProperties['storePassword']
        }
    }

    buildTypes {
        release {
            signingConfig signingConfigs.release
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

Part 4: GitHub Actions CI/CD Pipeline

Complete Workflow Configuration

Create .github/workflows/flutter-ci-cd.yml:

name: Flutter CI/CD Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]
  release:
    types: [ published ]

env:
  FLUTTER_VERSION: "3.24.0"
  JAVA_VERSION: "17"

jobs:
  # Continuous Integration Job
  test:
    name: Run Tests and Analysis
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Setup Java
      uses: actions/setup-java@v4
      with:
        distribution: 'temurin'
        java-version: ${{ env.JAVA_VERSION }}

    - name: Setup Flutter
      uses: subosito/flutter-action@v2
      with:
        flutter-version: ${{ env.FLUTTER_VERSION }}
        channel: 'stable'
        cache: true

    - name: Install dependencies
      run: flutter pub get

    - name: Verify formatting
      run: dart format --output=none --set-exit-if-changed .

    - name: Analyze project source
      run: flutter analyze --fatal-infos

    - name: Run unit tests
      run: flutter test --coverage

    - name: Upload coverage to Codecov
      uses: codecov/codecov-action@v3
      with:
        token: ${{ secrets.CODECOV_TOKEN }}
        file: coverage/lcov.info

  # Build Job
  build:
    name: Build APK and App Bundle
    runs-on: ubuntu-latest
    needs: test
    if: github.event_name == 'push' || github.event_name == 'release'

    steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Setup Java
      uses: actions/setup-java@v4
      with:
        distribution: 'temurin'
        java-version: ${{ env.JAVA_VERSION }}

    - name: Setup Flutter
      uses: subosito/flutter-action@v2
      with:
        flutter-version: ${{ env.FLUTTER_VERSION }}
        channel: 'stable'
        cache: true

    - name: Install dependencies
      run: flutter pub get

    - name: Decode keystore
      run: |
        echo "${{ secrets.KEYSTORE_BASE64 }}" | base64 --decode > android/app/keystore.jks

    - name: Create key.properties
      run: |
        echo "storeFile=keystore.jks" > android/key.properties
        echo "storePassword=${{ secrets.KEYSTORE_PASSWORD }}" >> android/key.properties
        echo "keyPassword=${{ secrets.KEY_PASSWORD }}" >> android/key.properties
        echo "keyAlias=${{ secrets.KEY_ALIAS }}" >> android/key.properties

    - name: Build APK
      run: flutter build apk --release

    - name: Build App Bundle
      run: flutter build appbundle --release

    - name: Upload APK artifact
      uses: actions/upload-artifact@v4
      with:
        name: release-apk
        path: build/app/outputs/flutter-apk/app-release.apk

    - name: Upload App Bundle artifact
      uses: actions/upload-artifact@v4
      with:
        name: release-aab
        path: build/app/outputs/bundle/release/app-release.aab

  # Deploy to Google Play Store
  deploy:
    name: Deploy to Play Store
    runs-on: ubuntu-latest
    needs: build
    if: github.event_name == 'release' && github.event.action == 'published'

    steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Download App Bundle artifact
      uses: actions/download-artifact@v4
      with:
        name: release-aab

    - name: Create service account JSON
      run: |
        echo "${{ secrets.GOOGLE_SERVICES_JSON }}" | base64 --decode > service-account.json

    - name: Deploy to Play Store
      uses: r0adkll/upload-google-play@v1.1.3
      with:
        serviceAccountJson: service-account.json
        packageName: com.yourcompany.yourapp
        releaseFiles: app-release.aab
        track: internal
        status: completed
        inAppUpdatePriority: 2
        userFraction: 0.5
        whatsNewDirectory: distribution/whatsnew
        mappingFile: build/app/outputs/mapping/release/mapping.txt

  # Notify on deployment
  notify:
    name: Send Deployment Notification
    runs-on: ubuntu-latest
    needs: deploy
    if: always()

    steps:
    - name: Notify Slack
      if: needs.deploy.result == 'success'
      uses: 8398a7/action-slack@v3
      with:
        status: success
        text: '🚀 Flutter app successfully deployed to Play Store!'
      env:
        SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

    - name: Notify on failure
      if: needs.deploy.result == 'failure'
      uses: 8398a7/action-slack@v3
      with:
        status: failure
        text: '❌ Flutter app deployment failed!'
      env:
        SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

Part 5: Advanced Pipeline Features

Multi-Environment Deployment

strategy:
  matrix:
    environment: [internal, alpha, production]
    include:
      - environment: internal
        track: internal
        user_fraction: 1.0
      - environment: alpha
        track: alpha
        user_fraction: 0.1
      - environment: production
        track: production
        user_fraction: 1.0

Conditional Deployments

- name: Deploy to Internal Track
  if: github.ref == 'refs/heads/develop'
  uses: r0adkll/upload-google-play@v1.1.3
  with:
    track: internal

- name: Deploy to Production
  if: github.event_name == 'release'
  uses: r0adkll/upload-google-play@v1.1.3
  with:
    track: production

Part 6: Security Best Practices

1. Managing Secrets Securely

Required GitHub Secrets

Navigate to your repository → Settings → Secrets and variables → Actions:

KEYSTORE_BASE64          # Base64 encoded keystore file
KEYSTORE_PASSWORD        # Keystore password
KEY_PASSWORD            # Key password
KEY_ALIAS               # Key alias
GOOGLE_SERVICES_JSON    # Base64 encoded service account JSON
CODECOV_TOKEN          # Optional: for code coverage
SLACK_WEBHOOK_URL      # Optional: for notifications

Encoding Files to Base64

# Encode keystore
base64 -i upload-keystore.jks | pbcopy

# Encode service account JSON
base64 -i service-account.json | pbcopy

2. Environment-Specific Configurations

Create separate secret sets for different environments:

DEV_KEYSTORE_BASE64
STAGING_KEYSTORE_BASE64
PROD_KEYSTORE_BASE64

3. Secret Rotation Strategy

Rotate service account keys every 90 days
Use time-limited access tokens when possible
Implement secret scanning in your repository
Never commit secrets to version control

4. Access Control

# Restrict deployment to specific branches
if: github.ref == 'refs/heads/main' && github.event_name == 'push'

# Require manual approval for production deployments
environment:
  name: production
  url: https://play.google.com/store/apps/details?id=com.yourcompany.yourapp

Part 7: Enhanced Pipeline Features

Code Quality Gates

- name: Run custom lints
  run: flutter analyze --fatal-warnings

- name: Check code coverage threshold
  run: |
    COVERAGE=$(flutter test --coverage | grep -o '[0-9]*\.[0-9]*%' | head -1 | sed 's/%//')
    if (( $(echo "$COVERAGE < 80" | bc -l) )); then
      echo "Coverage $COVERAGE% is below threshold of 80%"
      exit 1
    fi

Dynamic Version Management

- name: Update version
  run: |
    VERSION_CODE=${{ github.run_number }}
    VERSION_NAME="${{ github.ref_name }}-${{ github.run_number }}"

    # Update pubspec.yaml
    sed -i "s/version: .*/version: $VERSION_NAME+$VERSION_CODE/" pubspec.yaml

Parallel Testing

test:
  strategy:
    matrix:
      test-type: [unit, widget, integration]
  steps:
    - name: Run ${{ matrix.test-type }} tests
      run: flutter test test/${{ matrix.test-type }}

Part 8: Troubleshooting Common Issues

Issue 1: Build Failures

Problem: Gradle build fails due to dependency conflicts

Solution:

- name: Clean build cache
  run: |
    flutter clean
    flutter pub get
    cd android && ./gradlew clean

Issue 2: Keystore Issues

Problem: Keystore not found or invalid

Solution:

- name: Verify keystore
  run: |
    if [ ! -f "android/app/keystore.jks" ]; then
      echo "Keystore file not found!"
      exit 1
    fi
    keytool -list -keystore android/app/keystore.jks -storepass ${{ secrets.KEYSTORE_PASSWORD }}

Issue 3: Play Console Upload Failures

Problem: Service account lacks permissions

Solution:

Verify service account has "Release Manager" role
Ensure app is properly linked in Play Console
Check track configuration (internal/alpha/beta/production)

Part 9: Monitoring and Notifications

Slack Integration

- name: Notify deployment status
  uses: 8398a7/action-slack@v3
  with:
    status: ${{ job.status }}
    fields: repo,message,commit,author,action,eventName,ref,workflow
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

Email Notifications

- name: Send email notification
  if: failure()
  uses: dawidd6/action-send-mail@v3
  with:
    server_address: smtp.gmail.com
    server_port: 465
    username: ${{ secrets.EMAIL_USERNAME }}
    password: ${{ secrets.EMAIL_PASSWORD }}
    subject: 🚨 Flutter CI/CD Pipeline Failed
    body: |
      The CI/CD pipeline for ${{ github.repository }} has failed.

      Commit: ${{ github.sha }}
      Branch: ${{ github.ref }}
      Author: ${{ github.actor }}

      Check the logs: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
    to: dev-team@yourcompany.com
    from: ci-cd@yourcompany.com

Part 10: Performance Optimization

Caching Strategy

- name: Cache Flutter dependencies
  uses: actions/cache@v4
  with:
    path: |
      ~/.pub-cache
      ${{ runner.tool_cache }}/flutter
    key: ${{ runner.os }}-flutter-${{ hashFiles('**/pubspec.lock') }}
    restore-keys: |
      ${{ runner.os }}-flutter-

- name: Cache Gradle dependencies
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}

Build Optimization

- name: Enable Gradle daemon
  run: |
    mkdir -p ~/.gradle
    echo "org.gradle.daemon=true" >> ~/.gradle/gradle.properties
    echo "org.gradle.parallel=true" >> ~/.gradle/gradle.properties
    echo "org.gradle.configureondemand=true" >> ~/.gradle/gradle.properties

Part 11: Advanced Security Measures

1. Secret Scanning

Add .github/workflows/security-scan.yml:

name: Security Scan

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  secret-scan:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
      with:
        fetch-depth: 0

    - name: Run TruffleHog OSS
      uses: trufflesecurity/trufflehog@main
      with:
        path: ./
        base: main
        head: HEAD

2. Dependency Vulnerability Scanning

- name: Run dependency audit
  run: |
    flutter pub deps --json | dart run security_audit

- name: Check for outdated packages
  run: flutter pub outdated --exit-if-outdated

3. Code Signing Verification

- name: Verify app signing
  run: |
    jarsigner -verify -verbose -certs build/app/outputs/bundle/release/app-release.aab

Part 12: Multi-Platform Support

iOS Deployment Extension

build-ios:
  name: Build iOS
  runs-on: macos-latest
  needs: test

  steps:
  - uses: actions/checkout@v4

  - name: Setup Flutter
    uses: subosito/flutter-action@v2
    with:
      flutter-version: ${{ env.FLUTTER_VERSION }}
      channel: 'stable'

  - name: Install dependencies
    run: flutter pub get

  - name: Build iOS
    run: flutter build ios --release --no-codesign

  - name: Build IPA
    run: |
      cd ios
      xcodebuild -workspace Runner.xcworkspace \
                 -scheme Runner \
                 -configuration Release \
                 -destination generic/platform=iOS \
                 -archivePath build/Runner.xcarchive \
                 archive

Essential Resources and Links

Google Play Console & APIs

Google Play Console - Main dashboard for app management
Google Cloud Console - Service account management
Google Play Developer API - API documentation
Play Console Help - Official support docs

GitHub Actions Resources

GitHub Actions Marketplace - Find reusable actions
Flutter Action - Official Flutter setup action
Upload Google Play Action - Play Store deployment

Security Tools

TruffleHog - Secret detection
GitGuardian - Secret monitoring service

Best Practices Checklist

Security

✅ Use GitHub Secrets for all sensitive data
✅ Encode binary files (keystore, service account) as Base64
✅ Implement secret rotation schedule
✅ Enable branch protection rules
✅ Use environment-specific deployments
✅ Implement secret scanning
✅ Never commit secrets to repository

Performance

✅ Cache Flutter and Gradle dependencies
✅ Use matrix builds for parallel testing
✅ Optimize Docker images if using containers
✅ Implement incremental builds
✅ Use artifact caching between jobs

Reliability

✅ Implement proper error handling
✅ Add retry mechanisms for flaky operations
✅ Use health checks before deployment
✅ Implement rollback strategies
✅ Monitor deployment success rates

Code Quality

✅ Run automated tests (unit, widget, integration)
✅ Enforce code formatting standards
✅ Implement static analysis
✅ Check code coverage thresholds
✅ Scan for security vulnerabilities

Monitoring Your Pipeline

Key Metrics to Track

Build Success Rate: Percentage of successful builds
Deployment Frequency: How often you deploy
Lead Time: Time from commit to production
Mean Time to Recovery: Time to fix failed deployments

Setting Up Monitoring

- name: Record metrics
  run: |
    echo "build_duration=${{ job.duration }}" >> metrics.log
    echo "commit_sha=${{ github.sha }}" >> metrics.log
    echo "deployment_time=$(date -u +%Y-%m-%dT%H:%M:%SZ)" >> metrics.log

Common Pitfalls and Solutions

1. Version Conflicts

Problem: Flutter/Dart version mismatches
Solution: Pin specific versions in workflow and use version matrix for testing

2. Keystore Management

Problem: Keystore security and access
Solution: Use Base64 encoding and GitHub Secrets, never commit keystore files

3. Play Console Permissions

Problem: Service account lacks necessary permissions
Solution: Grant "Release Manager" role and verify API access configuration

4. Build Artifacts

Problem: Large artifact sizes affecting pipeline performance
Solution: Implement artifact cleanup and use efficient compression

Conclusion

Implementing a robust CI/CD pipeline for your Flutter application transforms your development workflow from manual, error-prone processes to automated, reliable deployments. This setup ensures that every code change is thoroughly tested, properly built, and securely deployed to the Google Play Store.

Key benefits you'll experience:

Faster Release Cycles: Automated processes reduce deployment time from hours to minutes
Improved Code Quality: Automated testing catches issues before they reach production
Enhanced Security: Proper secret management and automated security scanning
Better Collaboration: Standardized processes make team collaboration smoother
Reduced Human Error: Automation eliminates manual deployment mistakes

Next Steps

Implement the basic pipeline and test with a simple Flutter app
Gradually add advanced features like multi-environment deployment
Set up monitoring and alerting for pipeline health
Establish a secret rotation schedule
Document your team's deployment processes

Remember, CI/CD is an iterative process. Start simple, monitor your pipeline's performance, and continuously improve based on your team's needs and feedback.

Additional Resources

Flutter DevOps Guide - Official Flutter deployment docs
Android App Bundle Guide - Google's app bundle documentation
GitHub Actions Documentation - Complete GitHub Actions reference

Happy coding, and may your deployments be ever smooth! 🚀

Setting Up Auto Scaling Groups and Load Balancer on AWS EC2: A Step-by Step Guide

Rishi Vachhani — Sun, 27 Apr 2025 08:30:09 +0000

Ensuring high availability and scalability for your application is crucial when deploying on AWS.

In this guide, we'll walk through setting up Auto Scaling Groups (ASG), an Application Load Balancer (ALB), and a Target Group on AWS EC2.
By the end, you'll have a fully functional architecture that dynamically scales based on demand.

Launch EC2 Instance Before setting up Auto Scaling, start by launching an EC2 instance and configuring it to serve traffic.

Install Nginx on the Instance
Once your instance is running, install an Nginx server to serve a default page:

sudo apt update && sudo apt install nginx -y

When you access the instance's public IP in a browser, you should see the default Nginx welcome page.

Create a Target Group A Target Group is needed to route traffic from the Load Balancer to the EC2 instances.

Steps to Create a Target Group:

Navigate to Target Groups in the AWS EC2 dashboard.
Click Create Target Group.
Select Instances as the target type.
Specify the port (80/443) and protocol (HTTP/HTTPS).
Attach the previously launched EC2 instances.
AWS will now check the health status of the instances.

Create an Application Load Balancer (ALB) The Load Balancer distributes incoming traffic across multiple instances, improving availability and reliability.

Steps to Create a Load Balancer:

Navigate to Load Balancers in the AWS dashboard.
Click Create Load Balancer and select Application Load Balancer.
Choose Internet-facing as the scheme.
Configure Security Groups to allow HTTP/HTTPS traffic.
Select Regions and Availability Zones as needed.
Attach the previously created Target Group.

Click Create Load Balancer.

Once created, you can access the instances using the Load Balancer's DNS name.

Create a Launch Template A Launch Template defines the instance configuration for Auto Scaling.

Steps to Create a Launch Template:

Navigate to Launch Templates in AWS.

Click Create Launch Template.
Choose an instance type (e.g., t2.micro, t3.medium).
Configure network settings and attach necessary storage.
Select Security Groups and Key Pairs for authentication.
Save and create the Launch Template.

Set Up an Auto Scaling Group (ASG) Auto Scaling ensures that your application scales up or down based on demand.

Steps to Create an Auto Scaling Group:

Navigate to Auto Scaling Groups in AWS.
Click Create Auto Scaling Group.
Select the previously created Launch Template.
Choose VPC settings and Subnets.
Define the desired number of instances to maintain.
Integrate with the Load Balancer and Target Group.
Configure additional settings like Scaling Policies.

Click Create Auto Scaling Group.

Configure Dynamic Scaling Policies A Dynamic Scaling Policy adjusts the number of instances based on traffic.

Steps to Configure Scaling Policies:

Navigate to Auto Scaling Groups.
Select Scaling Policies.
Define Scaling Conditions such as CPU utilization or request rate.
Choose Step Scaling or Target Tracking Scaling.
Set thresholds for scaling in and out dynamically.

Save the policy — AWS will now adjust instances automatically based on demand.

Final Architecture Overview
After completing these steps, your AWS setup will include:

✅ EC2 instances running Nginx
✅ An Application Load Balancer distributing traffic
✅ A Target Group managing instance health
✅ An Auto Scaling Group ensuring dynamic scaling

This architecture ensures high availability, fault tolerance, and scalability for your AWS-hosted applications.

Conclusion
By following this guide, you've successfully deployed a scalable and fault-tolerant AWS infrastructure using Auto Scaling, Load Balancer, and Target Groups.
This setup ensures your application remains highly available even during traffic spikes.

📌 For a detailed step-by-step guide with images, download the PDF here

👥 Thanks to @vikram_patel, @shreyansh_1904, @karmpatel, and @thisaakash for their collaboration.

Automating CPU and Memory Utilization Logging with Cron Jobs on Windows and Linux

Rishi Vachhani — Fri, 14 Mar 2025 16:08:58 +0000

Introduction

Monitoring system performance is crucial for maintaining a healthy and efficient computing environment. In this guide, we will automate the logging of CPU and memory utilization every 15 minutes using scheduled tasks in Windows and cron jobs in Linux. We will also ensure that a new log file is created daily.

Why This is Useful in Everyday Life

Automating system monitoring can greatly simplify daily operations, especially for developers, system administrators, and IT professionals. Instead of manually checking system resource usage, automated logging allows:

Early detection of performance issues – Identify spikes in CPU or memory usage before they cause major slowdowns or crashes.
Efficient troubleshooting – Logs provide historical data, making it easier to diagnose and resolve performance problems.
Better resource planning – Analyze usage trends over time to optimize system resources.
Peace of mind – Once set up, the script runs in the background without user intervention, ensuring continuous monitoring.

Setting Up the Python Script

Before setting up the scheduled jobs, let's create a Python script that logs CPU and memory utilization.

Install Required Dependencies

We will use the psutil module to fetch CPU and memory utilization. If you haven't installed it yet, run:

pip install psutil

Python Script to Log System Utilization

Create a script named system_monitor.py with the following code:

import psutil
import datetime
import os

def log_system_utilization():
    today = datetime.datetime.now().strftime("%Y-%m-%d")
    log_dir = "logs"
    os.makedirs(log_dir, exist_ok=True)
    log_file = os.path.join(log_dir, f"cpu_memory_log_{today}.txt")

    with open(log_file, "a") as f:
        timestamp = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
        cpu_usage = psutil.cpu_percent(interval=1)
        memory_usage = psutil.virtual_memory().percent
        log_entry = f"{timestamp} - CPU Usage: {cpu_usage}% | Memory Usage: {memory_usage}%\n"
        f.write(log_entry)
        print(log_entry)

if __name__ == "__main__":
    log_system_utilization()

This script:

Creates a log directory if it doesn’t exist.
Generates a new log file daily.
Logs CPU and memory usage every time it runs.

Scheduling the Script on Linux Using Cron Job

In Linux, we use cron jobs to automate script execution.

Step 1: Open the Crontab Editor

Run the following command:

crontab -e

Step 2: Add the Cron Job

Add the following line at the end of the file to run the script every 15 minutes:

*/15 * * * * /usr/bin/python3 /path/to/system_monitor.py

Explanation:

*/15 → Runs every 15 minutes.
* * * * → Runs every hour, day, month, and weekday.
/usr/bin/python3 → Path to the Python interpreter.
/path/to/system_monitor.py → Full path to the script.

Step 3: Save and Exit

Save the file and exit. The cron job will now run every 15 minutes.

Step 4: Verify the Cron Job

To list scheduled cron jobs, run:

crontab -l

Scheduling the Script on Windows Using Task Scheduler

On Windows, we use Task Scheduler to automate the script execution.

Step 1: Open Task Scheduler

Press Win + R, type taskschd.msc, and hit Enter.

Step 2: Create a New Task

Click Create Basic Task.
Name it "System Utilization Logger" and click Next.

Step 3: Set the Trigger

Choose Daily and click Next.
Set the start time to midnight and repeat every day.
Click Next.

Step 4: Set the Action

Choose Start a Program and click Next.
Browse to the Python executable (e.g., C:\Python39\python.exe).
In the Add arguments field, enter the full path to system_monitor.py, e.g.:

   "C:\path\to\system_monitor.py"

Click Next and then Finish.

Step 5: Modify Task to Run Every 15 Minutes

Open Task Scheduler Library, right-click the created task, and select Properties.
Go to the Triggers tab and click Edit.
Select Repeat task every 15 minutes and Stop after 1 day.
Click OK and Apply.

Step 6: Test the Task

Right-click the task and select Run to ensure it executes correctly.

Conclusion

By following this guide, you've successfully automated system monitoring on both Linux and Windows. The script now runs every 15 minutes, generating daily logs to track CPU and memory utilization. This setup helps in proactive system monitoring and can be further enhanced with alert mechanisms or cloud storage integrations.

How This Makes Life Easier

Saves Time & Effort: No need to manually check system performance.
Improves System Stability: Prevent unexpected failures by analyzing logs.
Enhances Troubleshooting: Quickly identify patterns of high CPU/memory usage.
Scalable & Automated: Works on any system without manual intervention.

With this setup in place, you can focus on other important tasks while ensuring your system's performance is continuously monitored. 🚀

Let me know in the comments if you have any questions or suggestions!

@vikram_patel , @thisaakash , @shreyansh_1904, @karmpatel Thanks for colloborations.

Understanding Runlevels in Linux: A Complete Guide

Rishi Vachhani — Sat, 08 Mar 2025 05:42:08 +0000

Linux is a powerful and flexible operating system used in servers, embedded systems, and desktops worldwide. One of the essential components of Linux system administration is runlevels. Runlevels define the state of a Linux system by controlling the services and processes that run at startup.

Whether you’re troubleshooting boot issues or managing system services, understanding runlevels can significantly improve your Linux administration skills. In this blog, we’ll explore what runlevels are, where they are used, how to check the current runlevel, how to change it, and real-world use cases.

What Are Runlevels in Linux?

A runlevel in Linux is a mode of operation that determines what processes and services are active at a given time. Different runlevels are predefined for various system states, such as single-user mode, multi-user mode, or GUI mode. Traditionally, runlevels range from 0 to 6, each serving a specific purpose.

Standard Runlevels in Linux

The standard runlevels in SysVinit-based Linux distributions are:

Runlevel	Description
0	Halt (Shutdown)
1	Single-user mode (Maintenance Mode)
2	Multi-user mode without network
3	Full multi-user mode (CLI)
4	Unused (customizable)
5	Multi-user mode with GUI
6	Reboot

However, modern Linux distributions such as Ubuntu (16.04+), RHEL 7+, and CentOS 7+ have replaced SysVinit with systemd, where targets are used instead of runlevels.

Where Are Runlevels Used?

Runlevels are used in various scenarios, including:

System Boot Management — Define what services should start during boot.
Troubleshooting — Switching to single-user mode (Runlevel 1) helps in fixing critical system issues.
Server Configurations — Servers often run in Runlevel 3 (CLI mode) to save resources.
GUI vs CLI Switching — Users can switch between GUI (Runlevel 5) and CLI (Runlevel 3) as needed.
Custom System Modes — Runlevel 4 (unused by default) can be customized for specific requirements.

How to Check the Current Runlevel?

To check the current runlevel of your Linux system, use:

runlevel

Example Output:

N 5

Here, N indicates there was no previous runlevel change, and 5 represents the current runlevel (multi-user mode with GUI).

For systemd-based distributions, use:

systemctl get-default

Example Output:

graphical.target

This corresponds to Runlevel 5 in SysVinit.

How to Change Runlevels in Linux?

In SysVinit-based Systems

To switch to a different runlevel temporarily:

init <runlevel>

For example, to switch to runlevel 3:

init 3

Or:

telinit 3

To change the default runlevel permanently, edit the /etc/inittab file and modify this line:

default:5:initdefault:

Change 5 to your desired runlevel and reboot.

In Systemd-based Systems

To change the current runlevel (target) in systemd-based systems:

systemctl isolate multi-user.target

To set a default runlevel (target):

systemctl set-default multi-user.target

To switch back to GUI mode:

systemctl isolate graphical.target

Real-Time Use Cases of Runlevels

Recovering a Broken System — Boot into single-user mode (Runlevel 1) to fix misconfigured files or disk errors.
Running a Server Efficiently — Use Runlevel 3 (multi-user CLI mode) to optimize performance by disabling GUI.
Switching to Maintenance Mode — If you need to perform updates or maintenance, temporarily move to Runlevel 1.
Troubleshooting Network Issues — Runlevel 2 (no network) helps isolate networking problems.
Automating Startup Services — Customize runlevel scripts for specific startup configurations.

Conclusion

Understanding Linux runlevels is crucial for system administrators and advanced users. Whether you’re using an old SysVinit-based system or a modern systemd-based one, knowing how to check, change, and utilize runlevels can improve system management.

By mastering runlevels, you can efficiently manage services, troubleshoot issues, and optimize system performance. Start experimenting with different runlevels today to enhance your Linux skills!

@vikram_patel, @thisaakash , @shreyansh_1904 Thanks for colloborations.

Git Reset: Understanding and Using It Effectively

Rishi Vachhani — Thu, 06 Mar 2025 16:14:34 +0000

Git is a powerful Distributed Version Control System (DVCS) packed with commands that let developers manage their codebases efficiently. With its robust capabilities, Git provides flexibility for high-level operations while giving full access to its internals. It is fast, scalable, and an indispensable tool for modern development workflows.

What is Git Reset?

git reset is one of Git’s most versatile yet often misunderstood commands. It allows developers to undo changes at different levels of their repository. Depending on the options provided (--soft, --mixed, --hard), it manipulates three key components of Git:

Commit Tree (HEAD): Tracks the latest commit in the current branch.
Staging Index: Where changes are prepared for a commit.
Working Directory: Reflects local files and modifications.

Each mode of git reset changes these components in different ways.

The Three Modes of Git Reset

1. Soft Reset (`git reset --soft`)

Moves the HEAD pointer to the specified commit.
Keeps all changes in the staging area and working directory untouched.
Use case: When you want to modify or amend a commit without losing your staged changes.

 git reset --soft <commit-hash>

2. Mixed Reset (`git reset --mixed`) (default)

Moves the HEAD pointer to the specified commit.
Unstages changes but retains them in the working directory.
Use case: When you need to re-stage or redo your commit preparation.

 git reset --mixed <commit-hash>

3. Hard Reset (`git reset --hard`)

Moves the HEAD pointer to the specified commit.
Deletes all changes from both the staging area and the working directory.
Use case: When you want to discard all changes and return to a clean state.

 git reset --hard <commit-hash>

How Git Reset Works Internally

To understand how git reset works, let’s look at the three core components of a Git repository:

HEAD: Points to the latest commit in the current branch.
Index: The staging area for changes ready to be committed.
Working Directory: The local files and their current state.

Use Cases for Git Reset

Use --soft for minor adjustments: Great for tweaking or amending recent commits without losing any work.
Stick to --mixed for safe resets: Less destructive since it preserves changes in the working directory.
Be cautious with --hard: Only use it when you are sure you no longer need the uncommitted changes. Back up your work if necessary.
Avoid git reset on shared branches: Resetting history on shared branches can cause conflicts and confusion.
Leverage git reflog for recovery: If you reset to the wrong commit, git reflog can help you recover lost references.

Conclusion

Understanding git reset is essential for managing code efficiently. Whether making small corrections, undoing staged changes, or completely resetting a repository, knowing when and how to use git reset ensures a smooth development workflow.

By mastering git reset, developers can confidently navigate version history, fix mistakes, and optimize their Git experience.

@vikram_patel , @thisaakash , @shreyansh_1904 Thanks for collaborations.