Forem: rising_segun

Heroku Alternatives Decision Framework: What Actually Matters When Picking a PaaS

rising_segun — Fri, 30 Jan 2026 10:43:00 +0000

TL;DR: After Heroku killed their free tier, everyone rushed to Railway, Render, and Fly. Three years later, here is the framework that actually matters for picking between them based on billing model, not feature lists.

When Heroku discontinued their free tier in November 2022, hundreds of thousands of projects had to migrate. Most comparison posts you will find today are just feature lists. This guide focuses on what matters in practice after using all of these platforms in production: how they bill you and how that interacts with your traffic pattern and your tolerance for surprise invoices.

Quick Decision Helper

Need predictable costs? → Fixed tiers (Seenode, Render)
Traffic varies wildly? → Usage-based (Railway, Fly.io)
Just a static site? → Serverless (Vercel, Netlify)
Need enterprise features? → Render
Budget under $15/month? → Seenode or self-hosted

The One Thing Everyone Gets Wrong

People compare features. They should compare billing models.

Your choice is almost never about:

"Which has the best dashboard?"
"Which supports my framework?"
"Which has the nicest CLI?"

Most modern PaaS providers have reasonable dashboards, support the common languages and frameworks, and give you some batteries-included tooling. The real question is:

Which billing model matches your traffic pattern and your budget anxiety tolerance?

If you choose the wrong model, the platform can be technically great and still feel terrible to use, because every deploy becomes a question of, "What will the bill look like next month?"

Migrating from Heroku?

If you're coming from Heroku's free tier, the biggest shock is usually the cost. Heroku's free tier spoiled us—most alternatives start at $4–20/month. The good news: you're getting better performance, more predictable uptime, and actual support.

The closest "drop-in" replacements are Railway (similar workflow) and Seenode (similar economics). Render feels more "enterprise" but costs more.

The Three Billing Models That Emerged

Over the last few years, three dominant billing models have crystallized.

Model 1: Fixed Per-Node Tiers (Seenode, Render)

You pay a flat monthly rate for provisioned capacity. Whether your app is slammed 24/7 or idle for half the month, the bill barely moves.

Predictable: You know roughly what next month’s invoice will be.
Simple: You pay for the size and count of services and databases, not for each individual CPU cycle.
Wasteful at low usage: You still pay even when your app is mostly idle.

Best for: Steady traffic, budget-conscious teams, and people who hate billing surprises.

Example costs (Jan 2026):

Seenode: $4/month (Basic web + Tier 1 Postgres)
Seenode: $11/month (Standard web + Tier 2 Postgres)
Render: $13/month (Starter web + Basic Postgres)

If your app is always on and has relatively consistent traffic, fixed tiers tend to win. You trade theoretical efficiency for billing sanity.

Model 2: Usage-Based Metering (Railway, Fly.io)

You pay for what you actually use: per-minute compute, per-second CPU, per-request, per-GB of storage and bandwidth.

Efficient at low/variable usage: Quiet apps can be very cheap.
Scales smoothly with traffic: Spikes cost more, but you do not need to resize instances manually.
Unpredictable: If you do not monitor usage, bills can drift or spike.

Best for: Variable traffic, developers who monitor usage, or apps that must be 24/7 online but receive low or bursty traffic.

Example costs (Jan 2026):

Railway: $20–30/month typical (Pro plan with $20 included credit), can spike to $50+ with sustained traffic.
Fly.io: $0–15/month for hobby apps without managed Postgres, $43–50/month once you add managed Postgres.

Usage-based systems reward teams that:

Instrument and monitor their apps.
Understand their baseline traffic profile.
Are willing to occasionally dig through billing dashboards.

If that doesn't describe you, this model can feel like a tax audit every month.

Model 3: Serverless (Vercel, Netlify)

You pay per function invocation. There is no persistent application process; instead, your code runs on demand in short-lived serverless functions.

Amazing for JAMstack: Static-first sites, Next.js, Astro, Remix, etc.
Great for spiky traffic: You only pay when people actually hit your endpoints.
Awkward for stateful backends: Long-lived connections, background jobs, or session-heavy apps do not fit naturally.

Best for: JAMstack apps, modern React frameworks, marketing sites, and dashboards with lightweight APIs.

Not suitable for: Traditional backend frameworks like Django, Rails, or Express apps that rely on in-memory state, sticky sessions, or complex background processing.

If your mental model of “backend” is a long-running process with queues, WebSockets, and custom workers, serverless can feel like fighting the platform instead of using it.

What It Actually Costs (Real Numbers, Jan 2026)

To make this concrete, consider a typical full-stack app:

Web service with roughly 1 GB RAM
Managed Postgres with 1 GB storage (plus sensible defaults)

Here is what that looks like across platforms today:

Platform	Monthly Cost	Billing Model	What You Get
Seenode	$11	Fixed tier	Standard web + Tier 2 Postgres, always-on
Fly.io	$12–15	Usage-based	Self-managed Postgres (or $43–50/month with managed Postgres)
Railway	$20–30	Usage-based	Pro plan with $20 credit, can spike with traffic
Render	$57+	Fixed tier	Web service + Postgres with PITR and zero-downtime deploys

The cliff nobody mentions: Fly.io looks cheap ($0–15) for hobby apps without managed Postgres, but once you turn on managed Postgres, the bill often jumps up rather fast ($45-50). The platform is still good—but the mental model of it being "cheap" quietly disappears.

The Decision Framework

Stop comparing dashboards and feature checklists. Walk through these questions instead.

Question 1: Can you tolerate variable billing?

Yes, I monitor usage and I am okay with variance

Choose Railway or Fly.io. You get flexible scaling and can squeeze out cost efficiencies if you understand your workload.
No, I need predictable monthly costs

Choose Seenode or Render. Fixed tiers mean you know the number before the invoice arrives.

If you feel stress every time a cloud bill arrives, treat predictability as a core feature—not a nice-to-have.

Question 2: What is your budget ceiling?

Use this as a rough mapping for a single production app with a database:

$5–15/month
- Seenode (Basic or Standard tiers: $4–11/month)
- Self-hosted on a low-cost VPS (Hetzner, Contabo, etc.), if you are willing to manage infra.
$20–50/month
- Railway (Pro plan, potentially higher with sustained traffic)
- Seenode higher tiers if you need more resources but want fixed pricing.
$50–100/month
- Render (app + managed Postgres with PITR)
- Fly.io with managed Postgres and multi-region setups.
$100+/month
- Render with enterprise-style features (SSO, high availability, advanced backups).

These numbers change over time, but the shape of the tradeoffs does not.

Question 3: Do you need enterprise features?

Yes – compliance, SOC2, SSO, PITR, zero-downtime deploys are non-negotiable

Lean toward Render. It is opinionated, boring in the best way, and designed for teams that want stability and support more than they want to save $20/month.
No – I mostly need HTTPS, logs, deploys, and a Postgres database

Seenode or Railway are usually a better fit. They give you the essentials without pushing you up into enterprise pricing.

If legal and compliance teams are involved, the cheapest platform is rarely the right one.

Question 4: Is global distribution critical?

Yes – my users are spread across regions and latency matters

Fly.io shines here, with multi-region deployments as a first-class concept.
No – most users are in one region and latency is fine

Seenode, Railway, or Render will do the job. Focus on simplicity and billing, not on global replicas you may never need.

What I Actually Use (and Why)

Disclosure: I work on Seenode, so understand the bias. That said, here is the honest breakdown of what I reach for in different scenarios.

For hobby projects

Choice: Seenode Basic ($4/month)
Why: It is the cheapest always-on option with a database included that still feels like Heroku. I can git push, get HTTPS and logs, and forget about it. At $4/month, it is psychologically close to “free” but without the randomness of free-tier shutdowns.

For client projects

Choice: Render
Why: Clients pay for peace of mind. Render gives you:
- Managed Postgres with point-in-time recovery (PITR)
- Zero-downtime deploys
- A mature, predictable environment

The extra cost (often $57+/month for a typical setup) is easy to justify compared to the cost of a single outage for a paying client.

For high-traffic production on a coffee-priced budget

Choice: Self-hosted on Hetzner (or similar low-cost VPS) with Coolify or Dokploy.

If you need:

Many services
Heavy background workers
Higher traffic

…and still want to stay under $50/month, managed PaaS platforms become harder to justify. Self-hosting:

Compresses all infra cost into a single VPS bill.
Gives you full control over resource allocation.
Moves all responsibility for uptime onto you.

Downtime in this model is almost always your fault—bad deploys, poor monitoring, slow incident response. You save money but pay in operations time and cognitive load.

The Missing Costs Nobody Mentions

Looking only at base instance prices hides a lot of real-world cost. Four common gotchas:

Common mistake: Picking a platform based on the cheapest headline price, then getting surprised by egress fees, backup costs, or usage spikes. Always factor in the hidden costs.

1. Egress fees

Railway: $0.05/GB outbound
Fly.io: $0.02/GB outbound

If you run a webhook-heavy app, file-serving API, or anything data-intensive, egress can quietly add $50–200/month on top of your compute bill.

2. Railway’s credit system

Hobby: $1/month subscription with $5 usage credit
Pro: $20/month subscription with $20 usage credit

Once your actual usage exceeds that credit, metered charges apply. For small apps this is fine; for growing usage it can turn into an invisible ratchet until you look closely at the billing breakdown.

3. Stopped machines and storage

Fly.io continues billing storage even when machines are stopped: around $0.15/GB/month.

Stopping everything in a panic does not always reset the bill to zero. Persistent volumes, snapshots, and images keep ticking along until you explicitly delete them.

4. Database backups and safety nets

Render: Includes PITR on paid database plans. This is a genuine safety feature.
Railway / Fly.io: You usually need to:
- Configure backups yourself, or
- Rely on third-party tools, or
- Accept a more limited restore story.

This is invisible until something goes wrong—and then it is the only line item that matters.

The Closest Alternatives to OG Heroku

If what you really want is “git push and boom, we are live”, here is how the modern landscape looks:

Railway – Captures a lot of the Heroku magic. Simple, fast to onboard. The tradeoff is billing unpredictability if you are not watching usage.
Seenode – Leans into Heroku-style simplicity with Heroku-free-tier-style economics. At $4/month, it is psychologically very close to the old “free dyno” experience.
Render – The most production-ready choice, especially for serious projects and client work. More expensive, but you get strong defaults and guardrails.

Everything else in the ecosystem is either:

More serverless and front-end centric (Vercel, Netlify), or
More infra-heavy and DIY (Cloud providers, raw Kubernetes, self-hosting).

They can be great—but they are no longer "Heroku for everyone."

Quick Comparison Summary

Platform	Best For	Monthly Cost	Billing Model	Key Differentiator
Seenode	Hobby projects, predictable costs	$4–11	Fixed	Cheapest always-on with DB
Railway	Variable traffic, Heroku-like workflow	$20–30+	Usage-based	Simplicity + flexibility
Render	Client work, enterprise needs	$57+	Fixed	Production-ready defaults
Fly.io	Global distribution, bursty traffic	$0–50+	Usage-based	Multi-region by default

Key Takeaways

Billing model matters more than features — Match it to your traffic pattern
Hidden costs add up — Egress, storage, backups can double your bill
Predictability vs. flexibility — Choose based on your tolerance for billing surprises
Enterprise features cost money — Only pay for them if you actually need them
Self-hosting saves money — But you pay in operational overhead

So… What Should You Actually Do?

When choosing a PaaS in 2026, ask yourself one question first:

Is predictable billing or pay-as-you-go flexibility more important for this project?

Then layer on:

How much operational burden am I willing to accept?
Do I actually need global distribution, or does a single region work?
Is this a hobby app, client app, or revenue-critical system?

Once you answer those honestly, the "Heroku alternatives" list narrows itself down very quickly.

Use this checklist as you evaluate providers:

Your stack (language, framework, database)
Rough traffic pattern (requests/day or month)
Maximum monthly budget
Whether you need enterprise features (compliance, SSO, etc.)

With clear answers to those questions, you can quickly narrow down to one or two platforms whose billing models actually fit how your app is used.

Script automation explained – what it is, tools, benefits, and real examples

rising_segun — Sun, 17 Aug 2025 16:41:00 +0000

Script automation is the use of code, written in languages such as Bash, Python, or PowerShell, to automate repetitive or time‑consuming tasks in IT operations, system administration, and software development. Instead of performing tasks manually, teams can run scripts to trigger processes such as application deployment, data backups, file transfers, or system monitoring.

Many businesses adopt script automation to reduce human error, save time, improve efficiency, and accelerate DevOps workflows. As the demand for faster software delivery and continuous integration/continuous deployment (CI/CD) grows, script automation has become an essential part of modern DevOps strategies.

In this article, we explore the key benefits of script automation, popular scripting languages, top tools, and real‑world examples to help you apply it effectively in your DevOps and IT operations.

Best Scripting Languages for Automation
Benefits of Script Automation
Top 5 Script Automation Tools
- CloudRay
- ScriptRunner
- Ansible
- AttuneOps
- Jenkins
Examples of Script Automation in Bash
Wrapping up

Best Scripting Languages for Automation

There are several programming languages for script automation with unique strengths and characteristics. However, Bash scripting and Python remain the most widely used for system and DevOps automation.

Bash scripting: This is a shell command language known for its integration with Unix-based systems. It’s ideal for automating administrative tasks such as package installation, server bootstrapping, or even deployments.
Python: This is a high-level and general purpose language widely used for infrastructure automation, API scripting, and test pipelines in modern DevOps workflows.

Both Bash and Python have strengths and weaknesses depending on the use case. Below is a brief comparison:

Feature	Bash	Python
Best for	Shell scripting, Linux/Unix system tasks	Cross-platform automation, APIs, DevOps Workflows
Ease of Use	Simple for basic tasks; can get complex for logic-heavy work	Readable and maintainable, especially for large scripts
Tooling & Ecosystem	Native to Unix/Linux; tightly integrated with CLI tools	Rich library ecosystem for HTTP, automation, DevOps, etc.
Performance	Fast for command chaining and shell operations	Slightly slower but better for complex logic and data parsing
Error Handling	Primitive error handling (exit codes)	Built‑in exception handling
Learning Curve	Easier for those familiar with Linux shell	Easier for general-purpose programming and logic-heavy tasks

Aside from Bash and Python, there are several other scripting languages for automation with each with it’s unique use cases. Here are other scripting languages widely used for IT operations and DevOps automation:

Go (Golang): It’s unique for task concurrent executions
PowerShell: Designed for windows automation which is great for managing system configurations and registry task
Java: Often used for DevOps pipeline automation and integrations
Ruby: popular for automating configuration management
Perl: Powerful for file processing and text manipulation
JavaScript: Useful for automating web APIs or build processes

Each of these scripting languages offers unique strengths and limitations with each one best known for specific automation.

Benefits of Script Automation

The benefits of script automation are significant. As businesses scale their infrastructure and software operations, manual processes become time‑consuming, tedious, and error‑prone. Script automation boosts productivity, reduces human error, and accelerates software delivery and deployments.

Here are some benefits of using script automation in DevOps workflows and IT environments:

Cost Optimisation: Generally, script automation reduces the need for human input which eventually cuts down human work hours and minimize costly mistake. Teams saves both time and money by automating routine tasks.
Faster Tasks Execution: Automation can execute tasks in minutes even seconds compared to manual efforts which can take hours or days to execute. Script automation leads to faster incident recovery, deployments, and even overall performance.
Improved Accuracy and consistency: Manual operation is error prone. However, with script automation, operations are executed with consistency across various environments.
Enhanced Productivity: Script automation frees up teams from repetitive tasks. This allows team to focus on higher priority work such as innovation, workflow optimisation, and security hardening.
Seamless Integration with DevOps Tools Scripts can be easily integrated with CI/CD and configuration management tools. They can work with this tools efficiently to trigger deployments, automate test run, and so on.

Top 5 Script Automation Tools

Script automation tools has become important for teams that want to scale faster, increase productivity, and optimise costs. These tools empowers DevOps engineers, system admins, and cloud engineers to streamline operations.

Here are top five best script automation tool used by modern engineering teams:

CloudRay

CloudRay is a centralised Bash script automation platform that allows team to manage cloud and hybrid infrastructure. It allows team to run Bash scripts securely across hybrid or cloud infrastructure with the help of an Agent. This unique feature makes it suitable for automating repetitive infrastructure tasks such as Installations, deployments, server maintenance, backups and other infrastructure tasks.

Additionally, CloudRay’s schedules allow teams to schedules scripts across multiple environments. It also supports webhook triggers, making automation repeatable and event-driven. CloudRay stands out by combining the flexibility of scripting with the governance enterprise teams need to scale securely.

ScriptRunner

ScriptRunner is an automation platform specifically designed for PowerShell. It’s used by Windows admins to automate routine admin tasks with full auditability and governance. It provides a centralised environment for storing, managing, and executing PowerShell scripts with control and traceability. This tool also supports approvals, Active Directory integration, and delegated execution and logging.

Ansible

Ansible is an open source configuration management tool developed by Red Hat. It uses YAML-based playbooks for infrastructure wide automation and is popular for managing complex infrastructure at scale. Ansible unique characteristics is its agentless nature in which it can operate over SSH allowing easier adoption.

AttuneOps

AttuneOps is a script automation tool that provides advanced orchestration, scheduling and workflow management. It supports multiple scripting languages such as PowerShell, Bash, and Python.

It provides a centralised engine that allows team to automate across different OS environment consistency. It is used heavily in IT operations allowing teams to manage routine and repetitive tasks.

Jenkins

Jenkins is the widely used automation platform for CI/CD in DevOps workflow. It excels at executing automation scripts and scheduled jobs. Jenkins supports multiple scripts such as shell and Python script. This integrates with the source control tools, and offers robust scheduling workflows.

Examples of Script Automation in Bash

Bash script can be used to automate routine system administration tasks. These tasks can be installation of packages, database backups, provisioning of servers, and deployments.

Let’s look at some practical examples of Bash script automation that improves IT operations and DevOps workflows:

1. Automating LAMP Stack Installations

Bash script can be used to set up web servers quickly. You can automate the installation of LAMP stack (Linux, Apache, MySQL, PHP).

#!/bin/bash

set -e

# Update package list and install LAMP stack
sudo apt update
sudo apt install apache2 mysql-server php libapache2-mod-php -y

# Start services
sudo systemctl enable apache2
sudo systemctl enable mysql

This script will install all the required components needed and ensures Apache and MySQL automatically starts on system reboot.

2. Automating MySQL Backups to S3

Bash script can be used to automate and schedule routine database backup. For example, you can automate MySQL backups to Amazon S3 to ensure your data is consistently available offsite.

#!/bin/bash

set -e

# Variables
DB_NAME="mydb"
USER="root"
PASSWORD="yourpassword"
BACKUP_PATH="/tmp/mysql-backup.sql"
DATE=$(date +%F)

mysqldump -u $USER -p$PASSWORD $DB_NAME > $BACKUP_PATH
aws s3 cp $BACKUP_PATH s3://your-s3-bucket/$DB_NAME-$DATE.sql

You can also use it to automate backup of PostgreSQL to S3.

3. Automating Installation of WordPress

You can use Bash script to streamline and automate the deployment of CMS platform like WordPress. For example, you can automate the deployment of multiple WordPress site on a single server with the use of Bash script.

#!/bin/bash

set -e

# Update package list and install LAMP stack
sudo apt update
sudo apt install apache2 mysql-server php php-mysql -y

# Create directories for multiple sites
sudo mkdir -p /var/www/site1.com /var/www/site2.com

# Set permissions
sudo chown -R $USER:$USER /var/www/site1.com /var/www/site2.com

# Download and extract WordPress
wget https://wordpress.org/latest.tar.gz
tar -xvzf latest.tar.gz
cp -r wordpress/* /var/www/site1.com

Additionally, you can also use Bash script to automate the backup process of your WordPress site.

4. Deploy a Database Server

infrastructure engineers use Bash scipt to save time during infrastructure setup. You can use Bash script to automate the deployment of MySQL server on a Linux host.

#!/bin/bash

set -e

# Update package list and install MySQL server
sudo apt update
sudo apt install -y mysql-server
sudo systemctl enable mysql
sudo systemctl start mysql

Wrapping up

Script automation is an efficient way for DevOps and IT professionals to streamline DevOps tasks, IT operations, and reduce the likelihood for human error. Whether you’re automating deployments, backups, or security checks, having a well-structured approach enhances productivity and reliability. As infrastructure grow, so does the complexity to manage these growth. Script automation becomes not just a convenience but a necessity.

CloudRay is a leading platform for centralised Bash script automation across your cloud and server infrastructure. With CloudRay Agent, you can securely connect your cloud instances and on-premise servers, enabling real-time execution and monitoring of scripts from a single control panel. Our powerful Schedules feature allows you to automate scripts at custom intervals, whether hourly, daily, or triggered by specific events ensuring your DevOps workflows run reliably without manual intervention. CloudRay simplifies script management, increases operational efficiency, and gives teams full control over infrastructure automation, all from one unified interface.

Get Started with CloudRay

How to Automate AWS EC2, Backups and Monitoring Using Bash Scripts

rising_segun — Fri, 23 May 2025 00:00:00 +0000

Automating AWS infrastructure is a key practice for modern DevOps teams and cloud engineers. While Infrastructure as Code (IaC) tools like Terraform and CloudFormation have become the industry standard, Bash scripting remains a powerful and accessible way to automate AWS tasks. Bash scripts is especially useful for teams that wants lightweights, fast, and scriptable workflows without the overhead of learning a new Domain Specific Languages (DSL).

In this article, you will learn how to automate common AWS tasks using plain Bash scripts combined with AWS CLI. Whether you’re launching EC2 instances, taking automated EBS snapshots, or setting up monitoring scripts to track CPU utilisation, Bash provides a direct and flexible approach to get things done quickly. At the end, you will learn real-world use case on how to use bash script based automation more effectively using CloudRay a centralised platform for managing, scheduling, executing, and organising your scripts across environments.

Automation Use Cases
- 1. Automating EC2 Instance Launch with Bash Script
- 2. Automating EBS Volume Backups with Bash Script
- 3. Monitoring EC2 CPU Utilisation with Bash Script
Real World Use Case of Automating AWS Infrastructure using CloudRay
- EC2 Instance Launch with Auto-Tagging and Bootstrapping
- Running the Script on a Schedule with CloudRay
Wrapping Up

Automation Use Cases

AWS automation is not limited to large-scale infrastructure provisioning. With just Bash and the AWS CLI, you can automate a variety of real-world tasks such as launching of instances, backing up data, and monitoring system performance. These use cases are useful when you need a quick scripts to integrate into cron jobs, CI/CD pipelines, or even internal tools.

To follow along, ensure that your AWS CLI is properly installed and configured. If not, refer to the AWS CLI Setup Guide for a complete walkthrough on installing the CLI, creating key pairs, and configuring credentials.

Below are some of the most practical AWS automation tasks you can implement using Bash scripts.

1. Automating EC2 Instance Launch with Bash Script

Automating the creation, termination, and monitoring of EC2 instance is a common use case of AWS infrastructure management. With a simple bash script, you can reduce the manual steps and repeatability especially when managing development, staging, or even short-lived workloads for testing.

To begin, create a bash script file named launch-ec2:

nano launch-ec2

Add the following script to the file to launch EC2 instance, wait for it to become available, retrieve public IP address, and list the attached EBS volumes of the instance:

#!/bin/bash

# Launch a new EC2 instance
INSTANCE_ID=$(aws ec2 run-instances \
  --image-id ami-084568db4383264d4 \ # Replace with your preferred AMI
  --count 1 \
  --instance-type t2.micro \
  --key-name my-production-key \ # Replace with your existing key name
  --security-group-ids sg-0269249118de8b4fc \ # Replace with your Security Group ID
  --query 'Instances[0].InstanceId' \
  --output text)

echo "Launched EC2 Instance with ID: $INSTANCE_ID"

# Wait until instance is running
aws ec2 wait instance-running --instance-ids $INSTANCE_ID
echo "Instance is now running."

# Fetch public IP address
PUBLIC_IP=$(aws ec2 describe-instances \
  --instance-ids $INSTANCE_ID \
  --query 'Reservations[0].Instances[0].PublicIpAddress' \
  --output text)

echo "Public IP Address: $PUBLIC_IP"

# Get associated EBS Volume ID
VOLUME_ID=$(aws ec2 describe-instances \
  --instance-ids $INSTANCE_ID \
  --query 'Reservations[0].Instances[0].BlockDeviceMappings[0].Ebs.VolumeId' \
  --output text)

echo "EBS Volume attached to instance: $VOLUME_ID"

Here is what the script does:

launches an EC2 instance with a specified AMI, instance type, key pair, and security group
Waits for the instance to become active before proceeding
Retrieves and display public IP for SSH access or web server testing
Fetches the EBS Volume ID for later automation (e.g., backup snapshots or monitoring usage)

TIP

Make sure you replace the AMI and security group in the script with your own AMI and security group. To get the AMI, navigate to the EC2 Console, select AMIs from the sidebar, and use filters to locate the Amazon Linux or Ubuntu image you would like to use (copy its AMI ID)

Next, make your script executable:

chmod +x launch-ec2

Finally you can run the scripts:

./launch-ec2

Your result would be similar to the below

This shows that the instance was created successfully and both the IP address and the EBS volume is displayed. To confirm further, you can check the AWS console.

You can see the EC2 instance running successful.

2. Automating EBS Volume Backups with Bash Script

Another critical automation task is backing up your Elastic Block Store (EBS) volumes. Regular backups ensure you can recover your data in the event of accidental deletion, instance failure, or security breaches.

With a Bash script, you can create snapshots of your EBS volumes on demand or integrate them into a scheduled cron job for automated backups.

To get started, create a script named backup-ebs.sh:

nano backup-ebs.sh

Now add the following script to automate the creation of a snapshot for a given volume and tag it for easier identification:

#!/bin/bash

# Configuration
VOLUME_ID="vol-04fa2bf1eb229e072" # Replace with your volume ID
DESCRIPTION="Backup on $(date '+%Y-%m-%d %H:%M:%S')"
TAG_KEY="Purpose"
TAG_VALUE="AutomatedBackup"

echo "Creating snapshot of volume: $VOLUME_ID"

# Create snapshot
SNAPSHOT_ID=$(aws ec2 create-snapshot \
  --volume-id $VOLUME_ID \
  --description "$DESCRIPTION" \
  --query 'SnapshotId' \
  --output text)

echo "Snapshot created with ID: $SNAPSHOT_ID"

# Add tags to the snapshot
aws ec2 create-tags \
  --resources $SNAPSHOT_ID \
  --tags Key=$TAG_KEY,Value=$TAG_VALUE

echo "Snapshot $SNAPSHOT_ID tagged with $TAG_KEY=$TAG_VALUE"

Here is what the script does:

Takes a snapshot of a specified EBS volume using the AWS CLI
Adds a human-readable description that includes the date and time of the backup
Applies tags to the snapshot so you can easily search or filter for it in the AWS console

TIP

To find your EBS Volume ID, go to the EC2 Console → Volumes → and look under the “Volume ID” column. Be sure to copy the correct volume attached to your running instance.

Again, make the script executable:

chmod +x backup-ebs.sh

Finally, run the script:

./backup-ebs.sh

If successful, the output should display the snapshot ID along with a confirmation that it has been tagged

This backup script is a great candidate for CloudRay’s scheduler feature allowing you to run it every day, week, or hour without needing a separate server or cron job setup.

3. Monitoring EC2 CPU Utilisation with Bash Script

System performance monitoring is essential for maintaining the health and stability of your applications. While AWS CloudWatch provides detailed metrics and dashboards, you can also automate metric checks using a simple Bash script

One common metric to monitor is CPU utilisation. By querying CloudWatch, we can track when an EC2 instance’s CPU usage spikes above a defined threshold and respond accordingly.

Start Start by creating a script file named monitor-cpu.sh:

nano monitor-cpu.sh

Then paste the following code into the file:

#!/bin/bash

# Configuration
INSTANCE_ID="i-044166a99d5666bfc" # Replace with your instance ID
CPU_THRESHOLD=70 # Trigger alert if CPU > 70%
TIME_RANGE_MINUTES=60 # How far back to check

# Fetch CPU Utilisation
CPU_UTILISATION=$(aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilisation \
  --statistics Maximum \
  --period 300 \
  --start-time $(date -u -d "$TIME_RANGE_MINUTES minutes ago" +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --dimensions Name=InstanceId,Value=$INSTANCE_ID \
  --query 'Datapoints | sort_by(@, &Timestamp)[-1].Maximum' \
  --output text)

# Show retrieved metric
echo "CPU Utilisation for instance $INSTANCE_ID: $CPU_UTILIZATION%"

# Check against threshold
if (( $(echo "$CPU_UTILISATION > $CPU_THRESHOLD" | bc -l) )); then
  echo "⚠️ High CPU alert: $INSTANCE_ID at $CPU_UTILISATION%"
else
  echo "✅ CPU usage is within safe range."
fi

Here is what the script does:

Retrieves the maximum CPU utilisation from the last hour for a specific EC2 instance using CloudWatch metrics
Compares it to a defined threshold (For example, 70%)
Prints an alert if the usage exceeds the threshold, or a success message if within range

Make the script executable:

chmod +x monitor-cpu.sh

Finally, run the script:

./monitor-cpu.sh

Your result would be similar to the below

This lightweight monitoring script is perfect for integrating with a scheduled task on CloudRay. You can set it to run every 15 minutes and trigger custom actions like Slack alerts, emails, or remediation scripts whenever thresholds are breached.

Real World Use Case of Automating AWS Infrastructure using CloudRay

While Bash scripting gives you a powerful tool to automate AWS tasks locally, managing and reusing these scripts across environments becomes tedious without a centralised system. That is where CloudRay comes in.

CloudRay provides a Scripts dashboard where you can centrally manage, execute, and reuse your infrastructure automation scripts without relying on manual CLI or scattered cron jobs. it supports scheduling, allowing you to trigger EC2 provisioning or any AWS operation at predefined times.

Let’s walk through a real-world scenario where a DevOps engineer needs to launch a pre-configured EC2 instance every morning for development testing.

EC2 Instance Launch with Auto-Tagging and Bootstrapping

Before getting started, make sure your target servers are connected to CloudRay. If you haven’t done this yet, follow our servers docs to add and manage your server.

You can follow the below steps to create the script in CloudRay:

Create a CloudRay account at https://app.cloudray.io/
Go to Scripts > New Script
Name: Launch EC2 for Daily Dev Testing
Add code:

#!/bin/bash

# Optional: user data script (e.g., install NGINX on launch)
USER_DATA_SCRIPT='#!/bin/bash
sudo apt update -y
sudo apt install -y nginx
sudo systemctl enable nginx
sudo systemctl start nginx
'

echo "[$(date)] Starting EC2 launch process..." | tee -a {{log_file}}

# Launch EC2 instance
INSTANCE_ID=$(aws ec2 run-instances \
  --image-id "{{ami_id}}" \
  --count 1 \
  --instance-type "{{instance_type}}" \
  --key-name "{{key_name}}" \
  --security-group-ids "{{security_group_id}}" \
  --block-device-mappings "[{\"DeviceName\":\"/dev/xvda\",\"Ebs\":{\"VolumeSize\":{{volume_size}}}}]" \
  --tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value={{tag_name}}},{Key=Environment,Value={{environment}}}]" \
  --user-data "$(echo -n "$USER_DATA_SCRIPT" | base64 -w 0)" \
  --query 'Instances[0].InstanceId' \
  --output text)

if [[-z "$INSTANCE_ID"]]; then
  echo "[$(date)] Failed to launch instance." | tee -a {{log_file}}
  exit 1
fi

echo "[$(date)] Launched instance: $INSTANCE_ID" | tee -a {{log_file}}

# Wait until running
echo "[$(date)] Waiting for instance to enter running state..." | tee -a {{log_file}}
aws ec2 wait instance-running --instance-ids "$INSTANCE_ID"
echo "[$(date)] Instance is running." | tee -a {{log_file}}

# Fetch public IP
PUBLIC_IP=$(aws ec2 describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[0].Instances[0].PublicIpAddress' \
  --output text)

LAUNCH_TIME=$(aws ec2 describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[0].Instances[0].LaunchTime' \
  --output text)

echo "[$(date)] Public IP Address: $PUBLIC_IP" | tee -a {{log_file}}
echo "[$(date)] Launch Time: $LAUNCH_TIME" | tee -a {{log_file}}

# Output summary
echo ""
echo "================= EC2 Instance Launched ================="
echo "Instance ID : $INSTANCE_ID"
echo "Public IP : $PUBLIC_IP"
echo "Launch Time : $LAUNCH_TIME"
echo "Tag Name : {{tag_name}}"
echo "Environment : {{environment}}"
echo "========================================================"

This script provisions a fully tagged EC2 instance, installs NGINX on launch, and logs key metadata for auditing or monitoring.

Before running the scripts, you need to define values for the placeholders {{ami_id}}, {{instance_type}}, {{key_name}} {{security_group_id}}, and {{volume_size}} used in the scrips. CloudRay processes all scripts as Liquid templates. This allows you to use variables dynamically across different servers.

To ensure that these values are automatically substituted when the script runs, follow these steps to create a variable Group:

Navigate to Variable Groups: In your CloudRay project, go to “Scripts” in the top menu and click on “Variable Groups”.
Create a new Variable Group: Click on “Variable Group”.
Add the following variables:

ami_id: This is the AMI ID of your instance type (In this case it could be Ubuntu or any other operating system)
instance_type: This is the type of instance you want to use
key_name: The name of your private key in your AWS account
security_group_id: This is your security group ID
volume_size: The size of your EBS volume in GB

You can choose to run the script using CloudRay’s Script Playlists.

CloudRay uses Runlogs to execute scripts on your servers while providing real-time logs of the execution process.

To run the Launch EC2 for Daily Dev Testing, follow these steps:

Navigate to Runlogs : In your CloudRay project, go to the Runlogs section in the top menu.
Create a New Runlog : Click on New Runlog.
Configure the Runlog : Fill in the required details:

Server: Select the server you added earlier.
Script: Choose the “Launch EC2 for Daily Dev Testing”
Variable Group (optional): Select the variable group you created earlier.
Execute the Script : Click on Run Now to start the execution.

CloudRay will automatically connect to your server, run the Launch EC2 for Daily Dev Testing, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

You can Verify the instance also from the AWS console.

Running the Script on a Schedule with CloudRay

CloudRay also offers Schedules, allowing you to execute scripts automatically at specific intervals or times.

To execute this script daily at 8:00 AM without manual effort:

Navigate to Schedules: In your CloudRay dashboard, go to the “Schedules” tab.
Click “Add Schedule”: Start creating a new schedule.
Submit Schedule: Click “Submit” to activate your new schedule.

CloudRay will automatically execute the backup script at the scheduled time, ensuring that your EC2 instance is launched regularly everyday at 8AM.

Wrapping Up

Bash scripting provides a lightweight yet powerful way to automate AWS infrastructure tasks like EC2 provisioning, EBS backups, and performance monitoring. By combining these scripts with CloudRay’s scheduling and central management, you can build reliable, automated workflows without complex tooling. Start with the examples provided, customize them for your needs, and explore more automation possibilities.

Start today by signing up at https://app.cloudray.io and managed your bash scripts in a centralised platform.

Automating Web App Deployment with Terraform, GitHub, and CloudRay

rising_segun — Thu, 10 Apr 2025 10:50:50 +0000

CloudRay makes it easy to automate application deployment across your infrastructure. Instead of juggling manual steps or switching between tools, you can integrate CloudRay with Terraform and GitHub to build a seamless deployment pipeline.

In this tutorial, you will learn how to use Terraform to provision infrastructure on DigitalOcean, and then configure CloudRay to automate the deployment and management of a Node.js application. Additionally, You will also learn how to implement a simple CI/CD pipeline using GitHub Actions and CloudRay webhook, so every push to your repository automatically triggers a deployment.

By the end, you’ll have a fully automated system that provisions a server, deploys your web app, and keeps it updated with zero manual effort.

Prerequisites
Provisioning Infrastructure with Terraform
Configuring CloudRay for Automated Deployments
- Creating Deployment Script and CloudRay Webhook
- Integrating CloudRay Webhook in Terraform
Setting Up Continuous Deployment with GitHub and CloudRay
Conclusion

Prerequisites

Before you begin, ensure you have the following set up:

Terraform installed: You can install Terraform by following the official instructions
CloudRay account: Sign up at https://app.cloudray.io
DigitalOcean Personal Access Token: Create one via your DigitalOcean control panel. You will need this to authenticate Terraform with DigitalOcean
SSH key added to your DigitalOcean account: Create and upload a key using this guide. Make note of the name you assign—it will be used in your Terraform configuration
GitHub repository with a sample Node.js app: For this tutorial, we’ll use a sample Node.js app stored in GitHub. You can fork and clone this starter app or use your own

Provisioning Infrastructure with Terraform

Terraform lets you define infrastructure as code and supports a wide range of platforms through installable providers. Each provider acts as a bridge between Terraform and the APIs of the service you’re provisioning—like DigitalOcean in our case.

We will start by using Terraform to provision a virtual machine (droplet) on DigitalOcean. This will serve as the host for our Node.js application.

First, you create a project directory to house your infrastructure configuration files and navigate into the file:

mkdir infra-cloudray && cd infra-cloudray

Next, before running any terraform command, set the following environment variables to pass in your private SSH key and DigitalOcean API token securely. Replace the token value with your own generated token from the DigitalOcean dashboard:

export TF_VAR_pvt_key="~/.ssh/id_ed25519"
export TF_VAR_do_token="dop_v1_XXXXXXXXXXXXXXXXXXXXXXXXXXXX"

TIP

TF_VAR_ prefix allows you to pass environment variables to Terraform as input variables

Create a file named provider.tf which stores the configuration of the provider:

nano provider.tf

Then add the following configuration into the file:

terraform {
  required_providers {
    digitalocean = {
      source = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
  }
}

provider "digitalocean" {
  token = var.do_token
}

data "digitalocean_ssh_key" "my_key" {
  name = "my_key"
}

This file sets up the Terraform provider configuration, which tells Terraform to use the DigitalOcean plugin and specifies your authentication token. Replace my_key with the exact name you used when uploading your SSH key to DigitalOcean.

Create the second file named variable.tf:

nano variables.tf

Add the following configurations into the file:

variable "do_token" {
  description = "DigitalOcean API token"
  type = string
  sensitive = true
}

variable "pvt_key" {
  description = "Path to the private SSH key"
  type = string
  default = "~/.ssh/id_ed25519"
}

This file declares input variables, including the DigitalOcean API token and your SSH private key path.

Finally, create the main infrastructure file named www-cloudray.tf:

nano www-cloudray.tf

Similarly, add the following configuration inside the file:

resource "digitalocean_droplet" "www-cloudray" {
  image = "ubuntu-24-10-x64"
  name = "www-cloudray"
  region = "nyc3"
  size = "s-1vcpu-1gb"
  ssh_keys = [
    data.digitalocean_ssh_key.my_key.id
  ]

  connection {
    host = self.ipv4_address
    user = "root"
    type = "ssh"
    private_key = file(var.pvt_key)
    timeout = "2m"
  }
}

This is the main infrastructure file where we define our server. We use Ubuntu 24.10 and connect via SSH using your uploaded key. Furthermore, the configuration tells terraform to create a droplet named “www-cloudray”, use the SSH key you added to DigitalOcean and automatically connect connect using SSH for further provisioning.

Now, you initialize the terraform file:

terraform init

Next, you run the terraform plan to see your execution plan:

terraform plan

The + resource "digitalocean_droplet" "www-cloudray" shows that terraform will create a droplet resources named www-cloudray. Then, apply the configuration by running the command:

terraform apply

When prompted, type yes to confirm.

After deployment, you can inspect the created infrastructure and get the server’s IP address using:

terraform show terraform.tfstate

Now, you can add the server to CloudRay

Configuring CloudRay for Automated Deployments

Now that your DigitalOcean droplet is provisioned and added to CloudRay, let’s automate deployments using CloudRay’s script orchestration. This section covers:

Creating a deployment script and webhook
Modifying Terraform to trigger deployment of the application

Let’s get started.

Creating Deployment Script and CloudRay Webhook

First you create the deployment script by following these steps:

To create the setup script, you need to follow this steps:

Go to Scripts in your CloudRay project
Click New Script
Name: Deploy App Script. You can give it any name of your choice
Copy this code:

#!/bin/bash

# Update package lists
sudo apt update -y

# Install Nginx
sudo apt update 
sudo apt install -y nginx 

# Exit on error
set -e

# Install Node.js and npm
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

# Install PM2
sudo npm install -g pm2

# Clean and clone repo
sudo rm -rf "{{app_dir}}"
sudo mkdir -p "{{app_dir}}"
sudo chown -R $USER:$USER "{{app_dir}}"
git clone "{{repo_url}}" "{{app_dir}}"

# Install dependencies
cd "{{app_dir}}/app"
npm install

# Start application
pm2 start server.js --name nodeapp
pm2 save
pm2 startup

sudo bash -c "cat > /etc/nginx/sites-available/nodeapp" <<EOF
server {
    listen 80;
    server_name {{domain}} www.{{domain}};
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade \$http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host \$host;
        proxy_cache_bypass \$http_upgrade;
    }
}
EOF

# Enable config
sudo ln -sf /etc/nginx/sites-available/nodeapp /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

# SSL with Certbot
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d {{domain}} -d www.{{domain}} --email {{email}} --agree-tos --non-interactive
sudo systemctl reload nginx

Here is a breakdown of what each command in the Deploy App Script does:

Sets up the web server and runtime environment
Clones your Node.js repository and installs dependencies
Runs app as a managed background service
Routes web traffic to your Node.js app
Automatically provisions Let’s Encrypt SSL certificates

before using the scripts, you need to define values for the placeholders {{app_dir}}, {{repo_url}}, {{domain}}, and {{email}}, used in the scrips. CloudRay processes all scripts as Liquid templates. This allows you to use variables dynamically across different servers.

To ensure that these values are automatically substituted when the script runs, follow these steps to create a variable Group:

Navigate to Variable Groups: In your CloudRay project, go to “Scripts” in the top menu and click on “Variable Groups”.
Create a new Variable Group: Click on “Variable Group”.
Add the following variables:

{{app_dir}}: This is the application install path
{{repo_url}}: This is the GitHub repository URL
domain: The registered domain name for SSL certificate configuration
email: The email address associated with the SSL certificate (used for renewal alerts)

Since the script and variables are setup, proceed to creating a Webhook for the deployment script.

To create an Incoming Webhook in CloudRay follow these steps:

In CloudRay navigate and click on “Incoming Webhooks”
Click on “New Incoming Webhook” and fill in the detials to create the Webhook
Click “Create New Webhook”. This will generate a unique URL for your webhook

Now that your deployment script and CloudRay webhook are ready, the final step is to make sure Terraform can trigger that webhook

Integrating CloudRay Webhook in Terraform

We can update our Terraform configuration to trigger the CloudRay webhook after the droplet is successfully provisioned. Instead of using the remote-exec provisioner, we use a null_resource block with a local-exec provisioner, which runs the webhook call locally from the machine running Terraform.

Update your www-cloudray.tf file:

nano www-cloudray.tf

Add the following null_resource configuration outside the droplet block:

...
resource "null_resource" "trigger_cloudray_webhook" {
  provisioner "local-exec" {
    command = <<EOT
      curl -X POST \
        https://api.cloudray.io/w/58b3b37d-a77c-4b22-a6bc-ef3e2af8af34 \
        -H "Content-Type: application/json" \
        -d '{"test": false}'
    EOT
  }

  depends_on = [digitalocean_droplet.www-cloudray]
}
...

This tells Terraform to trigger the CloudRay webhook only after the www-cloudray droplet has been successfully created.

Your updated www-cloudray.tf file should now look like this:

This approach ensures that the webhook is triggered reliably during the provisioning process without the need for SSH access into the droplet.

Before applying your changes, reinitialize your Terraform project and upgrade any modules or providers:

terraform init -upgrade

Then apply the configuration:

terraform apply

Once terraform apply completes successfully, head over to your CloudRay Runlog to confirm that the webhook was received and the deployment job ran successfully.

Open your browser and navigate to your configured domain (e.g., https://www.mydomain.com). You should now see your application live and running on the newly provisioned droplet.

Setting Up Continuous Deployment with GitHub and CloudRay

To automate your deployment pipeline, we’ll integrate GitHub Actions with CloudRay so that any push to the main branch triggers a webhook, which then updates your server with the latest code.

First, let’s create the script on CloudRay to update always update the application. You can follow similar process as the above and use this code:

#!/bin/bash
set -e # Exit immediately if any command fails

# Navigate to project root
cd /var/www/nodeapp

echo "➡️ Pulling latest changes..."
git pull origin main

# Move to app directory
cd app

echo "📦 Installing dependencies..."
npm install

echo "🔄 Restarting application..."
pm2 restart nodeapp || (pm2 delete nodeapp && pm2 start server.js --name nodeapp)

Next, we also create a Webhook following similar steps as discussed earlier

Then go to the project repository (the node.js application), create a directory and file:

mkdir -p .github/workflows
touch .github/workflows/deploy.yml

Then add the following content to .github/workflows/deploy.yml:

name: Deploy to CloudRay

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger CloudRay Webhook
        env:
          WEBHOOK_URL: ${{ secrets.CLOUDRAY_WEBHOOK }}
        run: |
          curl -X POST "$WEBHOOK_URL" \
            -H "Content-Type: application/json" \
            -d '{"test": false}'

To add your CloudRay webhook to GitHub secrets, follow these steps:

Go to your GitHub repo Settings → Secrets → Actions
Click “New repository secret”
Name: CLOUDRAY_WEBHOOK
Value: Paste your CloudRay webhook URL
Click “Add secret”

Finally, let’s test the pipeline, make a changes on the application (modify the index.html file):

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Welcome</title>
</head>
<body>
    <h1>Greetings from CloudRay</h1>
    <p>This update was deployed automatically via GitHub → CloudRay 🎉</p>
</body>
</html>

Commit and push to main:

git add .
git commit -m "Test CI/CD pipeline"
git push origin main

Watch the process, GitHub Actions will show the workflow running.

Additionally, CloudRay will display the script execution in Run Logs.

Finally, visit your domain to see changes live within seconds.

Conclusion

By following this guide, you’ve successfully built a complete infrastructure automation and CI/CD pipeline that combines Terraform, DigitalOcean, CloudRay, and GitHub Actions.

The entire process from server creation to application updates now happens automatically whenever you push code changes, giving you more time to focus on development rather than deployment tasks.

Ready to streamline your own deployment workflow? Sign up for CloudRay today and experience the power of infrastructure automation firsthand.

Get Started with CloudRay

Deploy a Laravel Application using CloudRay

rising_segun — Thu, 03 Apr 2025 12:34:35 +0000

CloudRay simplifies infrastructure deployment through automation, making it an ideal choice for managing Laravel applications with Caddy. It automates the entire deployment process, reducing manual effort and ensuring a seamless, repeatable setup.

In this guide, you will learn the process of deploying a Laravel application with Caddy using CloudRay. You will learn how to create a detailed automation script for setting up the system, installing dependencies, deploying Laravel, and configuring Caddy as the web server. Caddy simplifies the process by automatically handling HTTPS (SSL/TLS) with Let’s Encrypt, ensuring your application is secure by default.

By the end of this guide, you will have a fully functional Laravel application hosted on an optimised server environment with automatic SSL support provided by Caddy.

Prerequisites
Assumptions
Create the Automation Script
- System Setup Script
- Install Composer and Database Setup Script
- Laravel Deployment Script
Create a Variable Group
Running the Script with CloudRay
Troubleshooting
Related Guides

Prerequisites

Before getting started, make sure you have the following prerequisites in place:

A CloudRay account at https://app.cloudray.io/
A cloud server accessible via SSH: If you don’t already have a cloud server, you can get one from popular providers like AWS, DigitalOcean, and Google Cloud. Ensure the server has at least 4GB of RAM, and a minimum of 20GB SSD
SSH credentials: Ensure you have access to the necessary SSH keys or login credentials to access your server. If you don’t have an SSH key set up, follow this guide to create one and add it to CloudRay
The servers are added to CloudRay: Before proceeding, make sure your server is connected to CloudRay. If you haven’t done this yet, follow this guide to add and manage your server

NOTE

This guide uses Bash scripts, providing a high degree of customisation. You can adapt the scripts to fit your specific deployments needs and environment.

Assumptions

This guide assumes you’re using Rocky Linux 9 as your server’s operating system. If you’re using a different version or a different distribution, adjust the commands accordingly

Create the Automation Script

To streamline the deployment process, you can use three automation scripts

System Setup Script: Installs all the Lavarel application and systems dependencies
Install Composer and Database Setup Script: Installs composer and setup the Laravel database
Laravel Deployment Script: automates cloning, configuring, and deploying a Laravel app with Caddy

Let’s begin with the System Setup Script

System Setup Script

To create the System Setup Script, you need to follow these steps:

Go to Scripts in your CloudRay project
Click New Script
Name: System Setup Script. You can give it any name of your choice
Copy this code:

#!/bin/bash

# exit on error
set -e

# Update system
sudo dnf update -y

# Install required software
sudo dnf install -y mariadb-server php php-fpm php-common php-xml php-mbstring php-json php-zip php-mysqlnd curl unzip nano

# Start and enable services
sudo systemctl start mariadb php-fpm
sudo systemctl enable mariadb php-fpm

# Configure PHP-FPM
sudo sed -i 's/^;listen.owner =.*/listen.owner = www-data/' /etc/php-fpm.d/www.conf
sudo sed -i 's/^;listen.group =.*/listen.group = www-data/' /etc/php-fpm.d/www.conf

sudo systemctl restart php-fpm

# Set SELinux to permissive mode
sudo setenforce 0

# Add /usr/local/bin to secure path in sudoers
sudo sed -i '/Defaults\s\+secure_path = /s|\(.*\)|\1:/usr/local/bin|' /etc/sudoers

echo "System setup complete!"

Here is a breakdown of what each command in the System Setup Script does:

Updates the system to the latest packages
Installs MariaDB, PHP, and dependencies required for Laravel
Starts and enables services to launch on boot
Configures PHP-FPM to use www-data as the owner
Configures SELinux to be permissive (optional, for easier troubleshooting)
Adds /usr/local/bin to the secure path for sudo commands

Install Composer and Database Setup Script

Next, you need to install and setup the database for the Laravel application. To do so, follow similar steps as the above:

Go to Scripts > New Script
Name: Install Composer and Database Setup Script
Add code:

#!/bin/bash

# Exit on error
set -e

# Install Composer
curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer
sudo chmod +x /usr/local/bin/composer

# Verify Composer installation
composer --version

# Configure MySQL database
sudo mysql <<EOF
CREATE DATABASE {{db_name}};
CREATE USER '{{db_user}}'@'localhost' IDENTIFIED BY '{{db_pass}}';
GRANT ALL PRIVILEGES ON {{db_name}}.* TO '{{db_user}}'@'localhost';
FLUSH PRIVILEGES;
EOF

echo "Composer and MySQL setup complete!"

This is what the Install Composer and Database Setup Script does:

Installs Composer, a dependency manager for PHP
Verifies Composer installation to ensure it’s available system-wide
Configures MariaDB database by creating a database, user, and granting permissions

Laravel Deployment Script

The final script automates the cloning, configuration, and deployment of your Laravel application with Caddy. This script will handle the deployment process, ensuring your application is ready to serve traffic.

To create the Laravel Deployment Script, follow these steps:

Go to Scripts > New Script
Name: Laravel Deployment Script
Add code:

#!/bin/bash

# Exit on error
set -e

# install git
sudo dnf install git -y

# Install Caddy
sudo dnf install 'dnf-command(copr)' -y
sudo dnf copr enable @caddy/caddy -y
sudo dnf install caddy -y

# Start and enable Caddy
sudo systemctl start caddy
sudo systemctl enable caddy

# Clone Laravel project from GitHub
if [! -d "/var/www/html/{{repo_name}}"]; then
    echo "Cloning Laravel repository from GitHub..."
    sudo git clone https://{{github_access_token}}@github.com/{{github_user}}/{{repo_name}}.git /var/www/html/{{repo_name}}
else
    echo "Repository already exists. Fetching latest changes..."
    cd /var/www/html/{{repo_name}}
    sudo git fetch --all
    echo "Resetting to the latest version of the main branch..."
    sudo git reset --hard origin/main
fi

# Set correct permissions
sudo chown -R www-data:www-data /var/www/html/{{repo_name}}/storage
sudo chown -R www-data:www-data /var/www/html/{{repo_name}}/bootstrap/cache
sudo chmod -R 775 /var/www/html/{{repo_name}}/storage
sudo chmod -R 775 /var/www/html/{{repo_name}}/bootstrap/cache

# Update Laravel environment file
if [-f "/var/www/html/{{repo_name}}/.env"]; then
    echo "Updating existing .env file..."
    # Update existing variables
    sudo sed -i "s|^APP_URL=.*|APP_URL={{domain}}|" /var/www/html/{{repo_name}}/.env
    sudo sed -i "s|^DB_CONNECTION=.*|DB_CONNECTION=mysql|" /var/www/html/{{repo_name}}/.env
    sudo sed -i "s|^DB_HOST=.*|DB_HOST=127.0.0.1|" /var/www/html/{{repo_name}}/.env
    sudo sed -i "s|^DB_PORT=.*|DB_PORT=3306|" /var/www/html/{{repo_name}}/.env
    sudo sed -i "s|^DB_DATABASE=.*|DB_DATABASE={{db_name}}|" /var/www/html/{{repo_name}}/.env
    sudo sed -i "s|^DB_USERNAME=.*|DB_USERNAME={{db_user}}|" /var/www/html/{{repo_name}}/.env
    sudo sed -i "s|^DB_PASSWORD=.*|DB_PASSWORD={{db_pass}}|" /var/www/html/{{repo_name}}/.env
else
    echo "Creating new .env file..."
    cat <<EOL | sudo tee /var/www/html/{{repo_name}}/.env
APP_URL={{domain}}

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE={{db_name}}
DB_USERNAME={{db_user}}
DB_PASSWORD={{db_pass}}
EOL
fi

# Run Laravel setup commands
cd /var/www/html/{{repo_name}}
sudo php artisan key:generate
sudo php artisan migrate

# Configure Caddy
cat <<EOL | sudo tee /etc/caddy/Caddyfile
{{domain}} {
    root * /var/www/html/{{repo_name}}/public # Serve files from the Laravel public directory
    php_fastcgi unix//run/php-fpm/www.sock # Pass PHP requests to PHP-FPM
    file_server # Serve static files
}
EOL

# Start and enable Caddy
sudo systemctl start caddy
sudo systemctl enable caddy

# Install Firewall & Configure Rules
sudo dnf install -y firewalld
sudo systemctl start firewalld
sudo systemctl enable firewalld
sudo firewall-cmd --zone=public --permanent --add-service=http
sudo firewall-cmd --zone=public --permanent --add-service=https
sudo firewall-cmd --reload

echo "Laravel deployment and SSL setup complete!"

This is what the Laravel Deployment Script does:

Installs Git for repository cloning
Defines the GitHub repository and target directory
Clones the Laravel project or updates it if it already exists
Sets proper permissions for storage and cache directories
Runs Laravel migration and key generation to prepare the application
Deploy the application with Caddy

Create a Variable Group

Now, before running the scripts, you need to define values for the placeholders {{db_name}}, {{db_user}}, {{db_pass}}, {{github_access_token}}, {{github_user}}, {{repo_name}}, and {{domain}} used in the scrips. CloudRay processes all scripts as Liquid templates. This allows you to use variables dynamically across different servers.

To ensure that these values are automatically substituted when the script runs, follow these steps to create a variable Group:

Navigate to Variable Groups: In your CloudRay project, go to “Scripts” in the top menu and click on “Variable Groups”.
Create a new Variable Group: Click on “Variable Group”.
Add the following variables:

db_name: This is the name database for the Laravel application
db_user: Database user for the Laravel application
db_pass: Password for the database user
github_access_token: This is your GitHub personal access token for cloning the repository
github_user: This is your GitHub Username
repo_name: This is the name of the GitHub repository
domain: Domain name for the Laravel application e.g., myapp.com

Since the variables are setup, proceed to run the scripts with CloudRay.

Running the Script with CloudRay

Now that everything is setup, you can use CloudRay to automate the deployment of your Laravel Application

You can choose to run the scripts individually or execute them all at once using CloudRay’s Script Playlists. Since there are multiple scripts, using CloudRay playlists will help automate the execution sequence and save time.

Here are the steps to follow:

Navigate to “Script Playlists”: Click on the Scripts tab in the CloudRay interface
Click “Add Script Playlist”: This initiates the creation of a new playlist
Provide a Name: Give your playlist a unique name (For example “Automate Deployment and Management of Laravel Application”)
Add Scripts in Order: Select and add the scripts sequentially
Save the Playlist: Click “create playlist” to store your new playlist.

Once your script playlist is created, proceed with execution:

Navigate to Runlogs : In your CloudRay project, go to the Runlogs section in the top menu.
Create a New Runlog : Click on New Runlog
Configure the Runlog : Provide the necessary details:
Server: Select the server where your Laravel application will be installed
Script Playlist: Choose the playlist you created (For example “Automate Deployment and Management of Laravel Application”)
Variable Group: Select the variable group you set up earlier
Execute the Script : Click on Run Now to start the execution

Your Laravel Application is now seamlessly deployed and managed with CloudRay. That’s it! Happy deploying!. You can access it by visiting http://myapp.com

Troubleshooting

If you encounter issues during deployment, consider the following:

Caddy Fails to Start: Check the Caddy service status with sudo systemctl status caddy and restart it using sudo systemctl restart caddy
PHP-FPM Not Working: Ensure PHP-FPM is running with sudo systemctl status php-fpm and restart it using sudo systemctl restart php-fpm
SSL Certificate Not Issued: Verify your domain’s DNS records and ensure ports 80 and 443 are open in the firewall.
Laravel Application Not Loading: Check the .env file for correct database credentials and ensure the storage and bootstrap/cache directories have the correct permissions.
Database Connection Issues: Verify the database credentials in the .env file and ensure MariaDB is running with sudo systemctl status mariadb

If the issue persists, consult the Caddy Documentation or the Laravel Documentation for further assistance.

Related Guides

Get Started with CloudRay

Best Way to Install Docker on Kali Linux

rising_segun — Wed, 29 Nov 2023 20:34:40 +0000

INTRODUCTION

Are you finding it difficult to install Docker on your Linux machine?
Docker is a powerful platform that enables developers to build, ship, and run applications in containers. Installing Docker on Kali can be tasking. Running docker Linux is a straightforward process, and in this guide, we'll walk you through each step, explaining the command line scripts along the way. Let's get started.

PREREQUISITES

Before installing docker. it is important to get have the following prerequisites:

A kali Linux Machine (ensure it is up-to-date)
Access to the terminal with sudo privileges
Basic understanding of command line.

To install docker in your kali linux machine, follow these steps:

Step 1: Update packages List

To start the installation of docker in your machine, it is important to update your package lists. To do this, open your terminal and run the following command to ensure that your package lists are updated:

sudo apt update

output:

Step 2: Install Docker

Once the package lists are successfully installed, install Docker using the following command:

sudo apt install docker.io

output:

Step 3: Enable and Start Docker Services

Docker requires a service to be running in the background. This steps enables and start the docker service with the following commands:

sudo systemctl enable docker --now

output:

This command not only enables Docker to start on boot but also starts the service immediately.

Step 4: Check Docker Service Status

To ensure docker is up and running, it is important to check the status. Use the following command:

sudo systemctl status docker

output:

This command provides detailed information about the Docker service, including its current status. Look for Active to confirm that Docker is running.

Step 5: Add Your User to the Docker Group

This step is required to avoid sudo each time you want to use Docker, add your user to the Docker group:

sudo usermod -aG docker $USER

This step grants your user the necessary permissions to interact with the Docker daemon.

Step 6: Restart Your System

To apply the changes made by adding your user to the Docker group, restart your system. You can do this by signing out and signing back in or using the command:

sudo reboot

Step 7: Verify Docker Installation

Confirm that Docker is successfully installed by checking its version:

docker --version

output:

This command displays the installed Docker version, confirming that the installation was successful.

CONCLUSION

Congratulations on successfully navigating through the installation of Docker on your Kali Linux machine! Docker brings a new level of flexibility and efficiency to your development and deployment workflows. With containers, you can ensure consistency across different environments, making your life as a developer much smoother. Feel free to explore Docker's vast capabilities and revolutionize the way you package and deploy applications.
Happy coding!

A Beginner's Guide: Installing MongoDB on Ubuntu 🔥 in 5 Simple Steps 🚀

rising_segun — Wed, 13 Sep 2023 21:04:28 +0000

Looking for a Hassle-Free MongoDB Installation on Ubuntu? Your search ends here! Follow this comprehensive step-by-step guide to effortlessly set up your MongoDB database on any Ubuntu or Linux-based system.

By the end of this article, you’ll have mastered installing MongoDB on Ubuntu effortlessly. This comprehensive guide not only offers a step-by-step walkthrough but also delves into the tools and techniques, providing valuable insights for seamless execution.

Prerequisites

To successfully install MongoDB on your Linux-based system, the following must be done:

knowledge of MongoDB
A general knowledge of working with command line/shell commands
Ubuntu or other Linux-based operating systems on the host workstation.

Steps to Install MongoDB on Ubuntu

MongoDB installation on Ubuntu is a simple process that allows you to set up a powerful and versatile NoSQL database on your system. By following a few simple steps, you can have MongoDB up and running in no time.

Step 1: Import MongoDB Repositories

It is important to ensure the legitimacy and integrity of the packages when installing MongoDB on Ubuntu. Ubuntu's Package Management system uses GPG keys to validate package signatures, adding an extra layer of security. To begin the MongoDB installation, you must first import the MongoDB Public GPG key into your Ubuntu system. The MongoDB Public GPG key can be imported with the following terminal command:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10

Create a Source list for your MongoDB installation next. To accomplish this, use the following command to create the "/etc/apt/sources.list.d/mongodb-org-3.4.list" list file:

echo "deb http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list

With your list file now created, you can install the Local Package repository. To do this, you can use the following command:

sudo apt-get update

Step 2: Installing MongoDB Packages

You now need to install the latest stable version of MongoDB on your system. Use the below command:

sudo apt-get install -y mongodb

If you wish to install a certain version of MongoDB on your system, you must specify the version for each component package when you install it. For example, installing a specific version. run the following command:

sudo apt-get install -y mongodb-org=3.4 mongodb-org-server=3.4 mongodb-org-shell=3.4 mongodb-org-mongos=3.4 mongodb-org-tools=3.4

Step 3: Launching MongoDB as a Service on Ubuntu

Now that MongoDB is up and running, you must build a Unit file to assist your system in understanding the resource management process. For example, the most widely used Unit file determines how to start, stop, or manage a service automatically.
To do this, you can create a configuration file, “mongodb.service in /etc/systemd/system”, that will help manage the MongoDB system.

sudo vim /etc/systemd/system/mongodb.service

Next, copy the following information in your configuration file:

Now that the configuration file has been produced, use the following command to update the system service:

systemctl daemon-reload

Next, start the updated systemd service for your MongoDB instance:

sudo systemctl start mongodb

Once the instance is running, check to see if MongoDB launched on port 27017. To accomplish this, use the "netstat" command as follows:

netstat -plntu

To confirm if your MongoDB instance started successfully, you need to use the status command as:

sudo systemctl status mongodb

Now, you can now enable auto-start functionality for your system as follows:

sudo systemctl enable mongodb

For an instance you want to start or restart the MongoDB instance running on your Ubuntu installation, run the below commands:

sudo systemctl stop mongodb

sudo systemctl restart mongodb

Step 4: Configuring and Connecting MongoDB

From the above steps, we have successfully installed MongoDB service. This step shows how to install MongoDB. To do this, open the Mongo Shell and switch to the database admin mode using the following command:

mongo
use admin

Now, create a root user for your MongoDB installation and exit the Mongo Shell as follows:

db.createUser({user:"admin", pwd:”password", roles:[{role:"root", db:"admin"}]})

Note: you can replace the user and pwd with your preferred choice.

with this setup, you can now connect with your MongoDB, by first restarting MongoDB and then using the following command:

mongo -u admin -p admin123 --authenticationDatabase admin

you’ll now be able to see MongoDB set up a connection. You can use the “show dbs” command as follows to open a list of all available databases. With all these, you’ve successfully installed MongoDB on Ubuntu.

Step 5: MongoDB Tuning

Scaling MongoDB is simple and may be done horizontally or vertically. This is critical for the Database's optimal performance. Horizontal scaling involves the addition of server resources such as RAM and CPUs, whereas vertical scaling involves the addition of servers to the configuration. Several factors influence the performance of the MongoDB Database, including memory usage, the number of concurrent connections, and the WiredTiger Cache, among others. MongoDB's default storage engine is WiredTiger, which saves 50% of RAM. This indicates that 8GB of RAM will have a memory preserver of 0.5*(8-1) for WiredTiger. Use the following command to check use statistics and determine whether modifications are needed.

From the above result, some of the key points to note are listed below.

wiredTiger.cache.maximum bytes configure
wiredTiger.cache.bytes currently in the cache
wiredTiger.cache.pages read into cache
wiredTiger.cache.pages written from cache
wiredTiger.cache.tracked dirty bytes in the cache

To check the usage of WiredTiger Concurrency Read and Write Ticket, follow the command given below.

Conclusion

In just 5 straightforward steps, you've embarked on a journey to harness the power of MongoDB on your Ubuntu system. By following this beginner's guide, you've not only successfully installed MongoDB but also gained valuable insights into managing databases on Linux.
With MongoDB in your toolkit, you're well-equipped to handle diverse data needs and build robust applications. So, go ahead and explore the endless possibilities this NoSQL database offers. Whether you're a developer, a data enthusiast, or a tech enthusiast, MongoDB on Ubuntu is your gateway to efficient data management.
Start your MongoDB adventure today and witness your projects scale and thrive like never before!"

CYBER THREAT ANALYSIS OF STATE SPONSORED CYBER OPERATION: 2005-2022

rising_segun — Mon, 27 Mar 2023 17:27:10 +0000

</> INTRODUCTION
As technology continues to advance, cyber-attacks are becoming more sophisticated and have become a significant threat to countries, organizations, and individuals worldwide. State actors often sponsor or carry out these attacks to achieve political, military, or economic objectives.
To better understand the trends and characteristics of sponsored cyber operation incidents from 2005 to 2022, we will analyze a dataset of such incidents. Through this analysis, we aim to provide valuable insights into the nature of these attacks and explore potential machine learning approaches to identify patterns and groups of incidents with similar characteristics. Our findings could help organizations and governments enhance their cybersecurity strategies and protect against future cyber threats.
</> DATA DESCRIPTION
The data was collected from Kaggle. Some exploratory data cleaning was done on the data using Microsoft Excel to make the data better for analysis and creation of insights. The updated data is hosted on my GitHub. Ultimately, the primary data source was the Council on Foreign Relations, an independent and nonpartisan American think tank specializing in U.S foreign policy and international relations.
</> METHODOLOGY AND RESULTS
The programming language used in this project is python, with the following libraries: pandas, numpy, plotly, seaborn, matplotlib, geopy, folium and scikit learn. The code to this project is here.
Before the data was analyzed, the data was cleaned and preprocessed. This involves removing irrelevant columns, handling missing values, and transforming the data into a format suitable for analysis. Also, we perform a Machine Learning algorithm called Latent Dirichlet Allocation (LDA) to identify topics from the description of cyber operation incidents.
First, we visualized the cyber operation incident over time with a linear graph which is represented below (Figure 1.)

Figure 1: Figure showing the trend of cyber operation incident over the years.

The graph shows a clear increase in the number of incidents over time, with a noticeable surge in incidents starting around 2014. From the graph, we can see that the number of cyber operation incidents steadily increased from 2005 to around 2014, with a few spikes in incident counts in the intervening years. However, starting around 2016, the number of incidents began to increase much more rapidly and reached a peak in 2018, with over 60 incidents recorded in that year. This began the rapid increase in cyber operation. This suggests that cyber operations are becoming more prevalent and sophisticated over time.
The target category that has been prevalent since 2005 till 2022. Figure 2 gives more insight into the category.

Figure 2: chart showing the target of the attack.

Based on the resulting plot, the government is still the most common target of cyber operations incidents, followed by the private sector and the military . military accounts for a smaller number of incidents in the provided dataset. This underscores the importance of prioritizing cybersecurity measures and training for government and private sectors, as well as civil society.

Figure 3: Various attack type carried out by Threat actors.

Figure 3. reveals that the most frequently observed attack type across the years is espionage, accounting for more than half of all recorded incidents perpetrated by threat actors. Notably, this trend aligns with the strategic objectives of many state-sponsored attackers who use covert means to access sensitive intelligence. Moreover, the prevalence of other attack types, such as denial of service, data destruction, financial theft, and sabotage underscores the diverse range of motives and objectives behind sponsored cyber-operations.

Figure 4: Types of cyber operations incidents over Time

The plot (Figure 4) shows the trends in the number of cyber operations incidents over time by type. It reveals that the most common types of incidents are espionage and theft, followed by disruption and defacement. The number of incidents of espionage and theft has been consistently higher than other types, indicating that these types are more prevalent and perhaps easier to carry out. The number of incidents of disruption and defacement has also increased over time, possibly due to the growing importance of technology and dependence on digital infrastructure in various sectors. The plot also shows a significant increase in cyber operations incidents starting around 2014, which corresponds to the surge in internet usage and widespread adoption of digital technologies in various sectors.

Figure 5: Map showing the state sponsored threat actors

The map generated shows the distribution of Cyber Operations incidents sponsored by various countries. From the map it is seen that most of the operation is coming from Europe and Eastern Asia. A chart was also created to create insight on the various continents of the state sponsored cyber attack was generated from (Figure 6).

Figure 6: Cyber-attack sponsors by region

The analysis revealed that North America and Europe were the most active regions in sponsoring cyber-attacks, with North America having the highest number of incidents. East Asia and the Middle East were also prominent sponsors of cyber-attacks, while South Asia, Southeast Asia, and Africa had a relatively smaller number of incidents. The result shows that the threat of cyber-attacks is not limited to specific regions or countries, as attackers can operate from anywhere in the world. The findings suggest that cybersecurity measures should be implemented globally to ensure the protection of critical infrastructure, businesses, and individuals.
Since 2005, thirty-four countries have been suspected of sponsoring cyber operations. China, Russia, Iran, and North Korea sponsored 77 percent of all suspected operations. Figure 7. Shows the top 5 sponsors by country of cyber operation.

Figure 7: Top sponsors by percentage of Incidents

Because of the nature of the data, so much insight could not be derived from various machine learning models. Nevertheless, topic model was carried out using Latent Dirichlet Allocation (LDA) on the descriptions of the cyber operations incidents’ dataset. The goal is to identify the main topics that emerge from the data.
First, we clean the text data by removing non-alphabetic characters, converting it to lowercase, and splitting the text into individual words. We then create a document-term matrix using CountVectorizer, which counts the frequency of each word in each document. Next, we fit the LDA model to the document-term matrix with 5 topics. We print the top 10 words for each topic to gain an understanding of the main themes in the dataset. Finally, we assign each incident to a topic based on the highest probability for that topic and visualize the distribution of incidents across topics using a countplot.

Figure 8: Distribution of Cyber Operations Incident Topics

The results show that the main topics of cyber operations incidents are:
Topic 0: Malware and hacking attacks.
Topic 1: Data theft and breaches
Topic 2: Espionage and state-sponsored attacks
Topic 3: Financial fraud and theft
Topic 4: Denial of Service attacks and infrastructure disruption
By understanding the main topics of cyber operations incidents, organizations and governments can prioritize their cybersecurity efforts and take appropriate measures to protect against these threats.
</> CONCLUSION
Overall, the analysis showed that the USA, China, Russia, Iran, and North Korea were the top sponsors of cyber operations between 2005 and 2022, accounting for more than 50% of all incidents in the dataset. These sponsors were also found to be the top sponsors in most of the categories, indicating that they were involved in a wide range of cyber operations. However, it is important to note that the data only includes incidents that have been attributed to a specific sponsor, and many incidents may have gone unattributed or misattributed, making the analysis only a representation of the known incidents.

click here for the jupyter notebook

click here for the github repository

Thank you for taking the time to read my article; your attention and support are greatly appreciated. It is my desire to share my ideas and thoughts with you, and I hope you find my content interesting and informative.

If you enjoyed reading my article, I encourage you to subscribe to receive future updates. By subscribing, you’ll never miss a post and you’ll be the first to know about my latest content.

GitHub
LinkedIn

Forem: rising_segun

Heroku Alternatives Decision Framework: What Actually Matters When Picking a PaaS

Quick Decision Helper

The One Thing Everyone Gets Wrong

Migrating from Heroku?

The Three Billing Models That Emerged

Model 1: Fixed Per-Node Tiers (Seenode, Render)

Model 2: Usage-Based Metering (Railway, Fly.io)

Model 3: Serverless (Vercel, Netlify)

What It Actually Costs (Real Numbers, Jan 2026)

The Decision Framework

Question 1: Can you tolerate variable billing?

Question 2: What is your budget ceiling?

Question 3: Do you need enterprise features?

Question 4: Is global distribution critical?

What I Actually Use (and Why)

For hobby projects

For client projects

For high-traffic production on a coffee-priced budget

The Missing Costs Nobody Mentions

1. Egress fees

2. Railway’s credit system

3. Stopped machines and storage

4. Database backups and safety nets

The Closest Alternatives to OG Heroku

Quick Comparison Summary

Key Takeaways

So… What Should You Actually Do?

Script automation explained – what it is, tools, benefits, and real examples

Contents

Best Scripting Languages for Automation

Benefits of Script Automation

Top 5 Script Automation Tools

CloudRay

ScriptRunner

Ansible

AttuneOps

Jenkins

Examples of Script Automation in Bash

Wrapping up

How to Automate AWS EC2, Backups and Monitoring Using Bash Scripts

Contents

Automation Use Cases

1. Automating EC2 Instance Launch with Bash Script

2. Automating EBS Volume Backups with Bash Script

3. Monitoring EC2 CPU Utilisation with Bash Script

Real World Use Case of Automating AWS Infrastructure using CloudRay

EC2 Instance Launch with Auto-Tagging and Bootstrapping

Running the Script on a Schedule with CloudRay

Wrapping Up

Automating Web App Deployment with Terraform, GitHub, and CloudRay

Contents

Prerequisites

Provisioning Infrastructure with Terraform

Configuring CloudRay for Automated Deployments

Creating Deployment Script and CloudRay Webhook

Integrating CloudRay Webhook in Terraform

Setting Up Continuous Deployment with GitHub and CloudRay

Conclusion

Deploy a Laravel Application using CloudRay

Contents

Prerequisites

Assumptions

Create the Automation Script

System Setup Script

Install Composer and Database Setup Script

Laravel Deployment Script

Create a Variable Group

Running the Script with CloudRay

Troubleshooting

Related Guides

Best Way to Install Docker on Kali Linux

INTRODUCTION

PREREQUISITES

Step 1: Update packages List

Step 2: Install Docker

Step 3: Enable and Start Docker Services

Step 4: Check Docker Service Status

Step 5: Add Your User to the Docker Group

Step 6: Restart Your System