CloudRay Articles

Top Cron Job Alternatives for Modern Engineering Team in 2026

Sun, 01 Mar 2026 00:00:00 GMT

Cron has long been the default Linux task scheduler, but many teams now look for reliable cron alternatives as infrastructure grows. Cron is easy to use, dependable for simple automation, and effective for handling scheduled tasks on a single server. However, cron jobs frequently become more difficult to monitor, troubleshoot, and oversee as infrastructure expands, particularly when dealing with numerous machines or production settings. As a result, a lot of teams start looking into cron job alternatives or newer automation scheduling tools that offer better observability and coordination across multiple servers.

In this article, we’ll explore the best cron alternatives based on operational needs in 2026, as well as when cron still makes sense and why teams move past it.

When Cron Still Works Perfectly
Built-in Cron Unix-like Alternative Tools
Top Modern Cron Job Alternatives in 2026
How to Choose the Right Cron Alternative
Conclusion

When Cron Still Works Perfectly

Cron is still a great tool for many automation tasks, even though it has some limitations. When used in the right way, it’s still one of the easiest and most reliable schedulers. For single-server environments or light automation, cron does exactly what it was built for — without extra complexity.

Cron works well when:

Tasks run on one machine
Jobs are simple and predictable
Failures are easy to detect manually
There aren’t many logging requirements
No central coordination is needed
Scripts don’t rely on external environments or shared infrastructure

Common examples include simple backups, log cleanups, temporary file removal, and other basic automation tasks.

However, when automation extends beyond one server or when reliability and visibility become critical, the problems usually start. At that point, teams start looking for tools that improve visibility, enable coordination, and support operational control.

Built-in Cron Unix-like Alternative Tools

Before we look at modern cron alternative platforms, it’s important to note that some Unix-like systems already have built-in alternatives to cron. These tools were designed to address specific scheduling limitations, such as missed jobs, system downtime, or limited control over task execution.

Tool	Description	Persistent Jobs	Missed Jobs Recovery
systemd timers	A modern scheduling mechanism built into systemd-based Linux systems, offering dependency control, logging integration, and better service management than cron.	Yes	Yes
Anacron	Designed for systems that are not always running. Executes scheduled jobs once the system becomes available after downtime.	No	Yes
Cronie	An enhanced cron implementation commonly used in modern Linux distributions, adding security and reliability improvements.	Yes	No
fcron	Combines features of cron and anacron, allowing flexible scheduling even when systems are intermittently offline.	Yes	Yes
bcron	A lightweight cron replacement focused on simplicity, security, and predictable execution behavior.	Yes	No

These tools fix some of cron’s problems, but they are mostly used as local task schedulers instead of full cron replacements for distributed infrastructure. As infrastructure grows, teams often need more visibility, coordination, and automation than local schedulers can give them.

Top Modern Cron Job Alternatives in 2026

When infrastructure grows beyond single servers, teams often need more than just scheduling based on time. Modern cron job alternatives extend traditional cron by adding centralized execution, distributed scheduling, observability, and operational control across environments.

Here is a quick side-by-side comparison of the most widely used modern cron job alternatives across four key factors: self-hosting capability, SaaS availability, multi-server support, and observability.

Tool	Type	Self-Hosted	SaaS	Multi-Server	Observability
ActiveBatch	Enterprise scheduler	No	Yes	Yes	Yes
CloudRay	Script automation platform	No	Yes	Yes	Yes
Airflow	Workflow orchestration	Yes	Partial	Yes	Yes
Rundeck	Job automation	Yes	Yes	Yes	Yes
Stonebranch	Enterprise automation	No	Yes	Yes	Yes
VisualCron	Windows automation	Yes	No	Limited	Yes
Celery	Distributed task queue	Yes	No	Yes	Partial
Sidekiq	Background job processor	Yes	No	Yes	Partial
Kubernetes CronJobs	Container scheduler	Yes	No	Yes	Partial
Jenkins	CI/CD automation	Yes	Partial	Yes	Yes
GitHub Actions	CI/CD scheduler	Partial	Yes	Limited	Yes
HashiCorp Nomad	Workload orchestration	Yes	Partial	Yes	Yes

The following is a useful guide to when each tool is best for a given situation, based on the size of the team, the complexity of the infrastructure, and the automation need.

1. ActiveBatch

ActiveBatch is a full-featured enterprise scheduler that provides a centralized platform for managing and automating tasks across multiple servers and environments. It offers a wide range of features, including job scheduling, task automation, and workflow orchestration. ActiveBatch is a great choice for teams that need to manage complex workflows and automate tasks across multiple servers and environments.

Best for: Large enterprises with heavy compliance requirements, batch processing, and cross-department automation needs.

Strengths:

Advanced workflow orchestration
Deep enterprise integrations
Strong SLA and dependency management
Centralized control of automation

Limitations:

Enterprise licensing costs can be significant
Requires ongoing operational maintenance
Overkill for small DevOps teams

When to choose it:

Use ActiveBatch when you need to automate across several business systems and need strict rules, approvals, and audit compliance.

2. CloudRay

CloudRay is a centralized script automation platform that centralizes how teams run, schedule, and monitor operational scripts across servers without managing cron jobs individually.

Best for: DevOps teams, developers, and system administrators who automate tasks across many servers or environments.

Strengths:

Execution first with scripts (no need for a workflow DSL)
Centralized scheduling for all machines
Execution history and run logs in real time
Works across cloud and on-prem servers
Lightweight compared to full orchestration platforms

Limitations:

Not designed for complex DAG workflows
Not a configuration management system

When to choose it:

If your teams already use Bash scripts but need more visibility, reliability, and centralized scheduling than cron can provide, choose CloudRay.

3. Apache Airflow

Apache Airflow is a free and open-source platform that lets you write, schedule, and monitor workflows programmatically. It is widely used for data engineering pipelines but also supports general-purpose job scheduling.

Best for: Data engineering teams that run ETL pipelines, ML workflows, or automation with complex dependencies.

Strengths:

Strong dependency management
Python-based workflow definitions
Distributed execution across multiple workers
Rich ecosystem integrations

Limitations:

Operationally complex
Requires ongoing infrastructure maintenance
Not great for automating simple systems

When to choose it:

Use Airflow when automation requires more than one pipeline to work together, rather than just scheduled scripts that run on their own.

4. Rundeck

Rundeck is an open-source automation platform that lets teams automate tasks across many servers and environments. It provides a single place to schedule jobs, coordinate workflows, and control access across servers.

Best for: Operations teams that need to control the execution of operational tasks across servers.

Strengths:

Role-based access control
Running jobs on multiple nodes
Automation driven by APIs
Mature ecosystem

Limitations:

Requires setup and maintenance
Job definition abstractions add operational complexity

When to choose it:

Choose Rundeck when teams need structured operational runbooks and limited access to infrastructure automation.

5. Stonebranch

Stonebranch is an enterprise-grade automation platform that focuses on managing workloads in mixed IT environments.

Best for:

Companies automating their work across mainframes, cloud platforms, and enterprise apps.

Strengths:

Hybrid infrastructure automation
Enterprise scalability
Advanced monitoring and reporting

Limitations:

Enterprise pricing model
Complex onboarding

When to choose it:

Best for businesses that need to replace legacy workload schedulers or coordinate automation across different types of environments.

6. VisualCron

VisualCron is a Windows-based platform for automating and scheduling tasks that uses a graphical user interface (GUI).

Best for:

Windows-heavy environments that need automation without requiring scripting expertise

Strengths:

Visual workflow interface
Strong Windows integration
Built-in task monitoring

Limitations:

Windows-focused and not designed for Linux/Unix environments
Limited large-scale distributed automation

When to choose it:

If most of your automation runs in Windows Server environments with little Linux infrastructure, choose VisualCron.

7. Celery

Celery is an open-source distributed task queue for running background tasks and asynchronous jobs in Python applications. It is commonly used with message brokers like Redis or RabbitMQ, enabling teams to distribute, schedule, and monitor tasks across multiple workers.

Best for:

Python-based applications that need background processing, distributed task execution, or application-level scheduling.

Strengths:

Distributed task execution across multiple workers
Integrates well with Python frameworks like Django and Flask
Supports message brokers like Redis and RabbitMQ
Built-in retry logic and task monitoring
Scales horizontally with worker nodes

Limitations:

Requires message broker infrastructure
Operational complexity grows with scale
Primarily tied to Python ecosystems

When to choose it:

If your application is written in Python and you need to run background jobs, scheduled tasks, or distributed workloads right inside the application architecture, choose Celery.

8. Sidekiq

Sidekiq is a background job processor for Ruby applications. It uses Redis as a message broker and lets developers offload jobs outside the main application process. Ruby on Rails applications often use Sidekiq to send emails, run scheduled jobs, and process data in the background.

Best for:

Ruby and Ruby on Rails applications that require background processing and scheduled job execution.

Strengths:

High-performance job processing using Redis
Seamless integration with Ruby on Rails
Simple setup for background jobs and scheduled tasks
Supports retries, job prioritization, and concurrency
Well-established ecosystem in the Ruby community

Limitations:

Primarily tied to the Ruby ecosystem
Requires Redis infrastructure
Scheduling capabilities are basic compared to dedicated automation platforms

When to choose it:

If your application is built with Ruby or Rails and you need a reliable way to run background tasks or scheduled jobs, choose Sidekiq.

9. Kubernetes CronJobs

Kubernetes CronJobs allow scheduled jobs to run inside Kubernetes clusters using cron-style scheduling syntax. They create Kubernetes Jobs on a defined schedule and run them inside containers, making them suitable for cloud-native environments.

Best for:

Teams running containerized workloads in Kubernetes that need to schedule batch or recurring jobs.

Strengths:

Native scheduling inside Kubernetes clusters
Uses familiar cron syntax
Runs jobs as containerized workloads
Integrates with Kubernetes observability and logging
Scales with cluster infrastructure

Limitations:

Only works inside Kubernetes environments
Requires Kubernetes operational knowledge
Monitoring and failure visibility may require additional tooling

When to choose it:

If your workloads are already running in Kubernetes and you need to run scheduled tasks as containerized jobs in the cluster, use Kubernetes CronJobs.

10. Jenkins

Jenkins is an open-source automation server widely used for continuous integration and continuous delivery (CI/CD). While Jenkins is not a dedicated job scheduler, many teams use it to automate recurring tasks such as running infrastructure scripts, generating reports, and performing maintenance.

Best for:

Engineering teams that already use Jenkins for CI/CD and want to schedule automated tasks on the same platform.

Strengths:

Mature ecosystem with thousands of plugins
Built-in job scheduling using cron-style triggers
Strong integration with CI/CD pipelines
Extensive automation capabilities across systems

Limitations:

Designed primarily for CI/CD workflows rather than task scheduling
Requires ongoing maintenance and plugin management
Can become operationally heavy for simple scheduled tasks

When to choose it:

Choose Jenkins when scheduled tasks are closely tied to CI/CD pipelines or when your organization already relies on Jenkins as a central automation platform.

11. GitHub Actions

GitHub Actions lets developers set up automated workflows directly inside GitHub repositories. Teams can use scheduled workflows with cron syntax to run maintenance tasks, dependency updates, or automation scripts at defined intervals.

Best for:

Teams that want to set up automation tasks right in their GitHub-based development process.

Strengths:

Built directly into the GitHub platform
Uses cron-style scheduling syntax
Easy integration with repositories and CI/CD pipelines
No infrastructure management required

Limitations:

Primarily tied to repository-based workflows
Not designed for running large operational workloads
Limited visibility for complex operational automation

When to choose it:

Use GitHub Actions when scheduled jobs are closely tied to repository operations such as CI tasks, maintenance scripts, or automated checks.

12. HashiCorp Nomad

HashiCorp Nomad is a platform for managing and scheduling workloads, both containerized and non-containerized, across clusters. Nomad supports periodic jobs, which let tasks run on a schedule. This makes it a more flexible option than cron in distributed environments.

Best for:

Organizations using HashiCorp tooling to manage workloads distributed across clusters.

Strengths:

Can schedule both containerized and non-containerized workloads
Supports cron-style scheduling for batch jobs
Integrates with other HashiCorp tools like Consul and Vault
Scalable and fault-tolerant cluster architecture
Flexible job specification format

Limitations:

More complex than traditional cron for simple scheduling needs
Requires cluster infrastructure and management
Not specifically designed for cron-style task scheduling
Learning curve for Nomad’s job specification format

When to choose it:

Choose Nomad when you need to schedule batch jobs or recurring tasks as part of a larger container orchestration or workload management strategy, especially if you’re already using other HashiCorp tools.

How to Choose the Right Cron Alternative

Not all cron alternatives solve the same problem. Some tools are built for application-level background jobs, while others are designed for multi-server workload automation or infrastructure scheduling. The best option for you will depend on your team size, environment, and operational needs.

Here are a few practical guidelines:

Use Celery or Sidekiq if:

Your application needs background job processing
Tasks are tightly integrated with your application code
You already run Python or Ruby services

Use Kubernetes CronJobs if:

Your workloads run in Kubernetes
Jobs are containerized
Scheduling needs to happen inside the cluster

Use Jenkins or GitHub Actions if:

Tasks are related to CI/CD workflows
Automation is tied to repository activity
Infrastructure automation is already handled by CI pipelines

Use Airflow if:

Workflows have complex dependencies
Tasks must run in a defined sequence
You are building data pipelines or ETL processes

Use infrastructure automation platforms (CloudRay, Rundeck, ActiveBatch, Stonebranch) if:

Scripts run across multiple servers
Teams need centralized scheduling and execution visibility
Operational automation must be audited and monitored

Choosing the right tool is less about replacing cron and more about understanding what kind of automation problem you are trying to solve.

Conclusion

Cron is still a reliable way to schedule simple tasks on a single server. But as infrastructure becomes more distributed and operational reliability becomes more important, many teams need more visibility and centralized control than traditional cron can provide. There are many modern cron alternatives, from Unix-native schedulers to enterprise automation platforms — each best suited to a different level of complexity. The right solution will depend on whether you need lightweight scheduling, workflow orchestration, or centralized automation across multiple servers.

Get Started with CloudRay

Why Cron Jobs Fail Silently in Production and How to Fix It

Thu, 12 Feb 2026 00:00:00 GMT

Cron jobs are one of the easiest tools we use in production, but they can also be one of the most annoying when something goes wrong. You set up a script, schedule it, and then forget about it, thinking it will work. Then, after a few days or weeks, you find out that it didn’t run at all. No warnings. No records. No errors. Nothing but silence.

This guide will show the most common reasons why cron jobs fail silently in production. It will give you real-life examples of what went wrong, and show you exactly how to fix each problem.

Common Causes of Silent Cron Failures and How to Fix Them
How CloudRay Helps You Avoid Silent Cron Failures

Common Causes of Silent Cron Failures and How to Fix Them

Here are some of the reasons why your cron jobs might be failing silently in production and how to fix them:

1. Cron Doesn’t Use Your Shell Environment

This is the most common reason cron jobs fail silently. When you run a script manually on your terminal, it uses the following:

Your shell environment (this could be Bash, Zsh, etc. depending on your Linux system)
Your path (that is $PATH)
Your environment variables, aliases, and functions.

However, cron jobs do not use any of these. Instead, it runs with limited environment, which means that a command that works well in your terminal might not work when cron runs it.

For example, this command works when run manually on the terminal:

aws s3 sync /data s3://my-bucket

But when run as a cron job, it fails because aws is not in cron’s PATH.

/bin/sh: 1: aws: not found

Fix: Always put the full paths to the command inside the cron script:

* * * * * /usr/local/bin/aws s3 sync /data s3://my-bucket

If you’re not sure of the location of the command, check the path with the which command:

which aws

Additionally, you can also log the PATH cron is using to confirm it’s correct:

echo $PATH >> /tmp/cron_path.log

2. Cron Uses `/bin/sh` Not Bash

Cron jobs use /bin/sh by default. It does not use Bash. This means if you use Bash specific syntax on your cron job, it will fail.

Here are common syntax elements that will break when used in cron jobs:

[[...]]
source
arrays
set -o pipefail
set -e

For example, this command will work interactively on your terminal but fail when run as a cron job:

[[ -f /tmp/file ]] && echo "Exists"

Fix: You need to tell cron explicitly which shell to use. You can do this by adding a shebang (#!) at the top of your script:

#!/bin/bash

[[ -f /tmp/file ]] && echo "Exists"

Also, you can force Bash as default directly in your crontab file:

* * * * * /bin/bash /opt/scripts/cleanup.sh

3. Cron Output Is Being Discarded

Cron sends output of the cron jobs to the local mailer. Most modern servers do not have email configured as a result, the outputs from cron jobs are discarded. Due to this, you often have jobs that actually failed but you never saw them.

Fix: One of the most effective ways is to redirect stdout and stderr to a log file:

* * * * * /opt/scripts/cleanup.sh >> /var/log/cleanup.log 2>&1

To make it even better, always rotate the log using logrotate to prevent it from growing endlessly. It’s important to note that cron jobs should be run with explicit logging.

4. Permissions and Ownership Issues

Cron jobs often fail because the user running the job doesn’t have permission to run the script or get to the files it needs.

This usually happens when:

The script is not executable
The user can’t write to a directory
The job relies on Docker or system-level commands
The script was created by another user

Fix: Make sure your script is executable and owned correctly:

chmod +x /opt/scripts/cleanup.sh
chown cronuser:cronuser /opt/scripts/cleanup.sh

Always do a quick test as the cron user to confirm permissions are correct:

su - cronuser -c "/opt/scripts/cleanup.sh"

If it fails, it will fail in cron too.

5. Relative Paths Break Under Cron

You have to tell Cron where your script is. It doesn’t run from your Git repo, project folder, or home directory.

For example, this command will fail silently if run as a cron job:

* * * * * cd scripts && ./cleanup.sh

This is because cron has no idea what scripts directory is.

Fix: You should always use absolute paths in your cron jobs:

* * * * * /opt/scripts/cleanup.sh

You can also explicitly set the working directory:

* * * * * cd /opt/scripts && ./cleanup.sh

Absolute paths are safer and far more predictable in production.

6. Missing Environment Variables

If you have environment variables in your script, cron does not load them by default. Cron does not load shell profile files like .bashrc, .zshrc, or .profile. This is one major reason why backup jobs, cloud uploads, or API calls fail silently in production.

For example, this command will work manually on the terminal:

export AWS_ACCESS_KEY_ID=xxx
export AWS_SECRET_ACCESS_KEY=yyy
./backup.sh

But will fail under cron because those variables are not defined in cron’s environment.

Fix: There are three options to fix this.

Option 1: Source a known environment file

* * * * * . /etc/profile && /opt/scripts/backup.sh

Option 2: Load variables inside the script

export AWS_ACCESS_KEY_ID="xxx"
export AWS_SECRET_ACCESS_KEY="yyy"

Option 3: Use a .env file with strict permissions and source it explicitly

* * * * * . /opt/scripts/.env && /opt/scripts/backup.sh

7. You’re Editing the Wrong Crontab

Even experienced engineers fall for this. The crontab for root user is different from the crontab for other users. So the job exists, but it’s not running because it’s in the wrong crontab.

Fix: When setting up cron jobs, always verify which crontab you’re editing:

crontab -l
sudo crontab -l
sudo crontab -u devops -l

If the job isn’t listed there, it’s not running there.

8. The Cron Daemon Isn’t Running

There are times when the cron daemon itself isn’t running. There are many reasons why this could happen, like the service crashing or being taken offline for maintenance. This will stop all of your cron jobs from running, and you might not even know about it.

Fix: You can check if the cron daemon is running:

systemctl status cron
# or
systemctl status crond

If the cron daemon is not running, you can start the daemon:

sudo systemctl start cron
sudo systemctl enable cron

9. Long-Running Jobs Overlap and Kill Each Other

Cron doesn’t care if your last job is still running.

A job can overlap with itself and fail in ways that are hard to predict if it takes longer than its scheduled time.

For example, if you have an active cron job:

* * * * * /opt/scripts/report.sh

If report.sh takes 90 seconds, multiple instances stack up.

Fix: Use a lock file to prevent multiple instances from running at the same time:

#!/usr/bin/env bash

LOCKDIR="/tmp/report.lock"

if ! mkdir "$LOCKDIR" 2>/dev/null; then
    echo "Report is already running"
    exit 1
fi

trap "rmdir '$LOCKDIR'" EXIT

# Run the report
/opt/scripts/report.sh

This ensures only one instance runs at a time.

10. Cron Jobs Inside Docker Aren’t Running at All

Cron does not run inside a Docker container by default. You need to explicitly install cron, start the cron daemon and make sure it supports foreground mode.

Fix: Make sure your cron runs in foreground:

# Install cron
RUN apt-get update && apt-get install -y cron

# Start cron in foreground
CMD ["cron", "-f"]

Also verify crontab is present in the container:

cat /etc/crontab

11. Failure to Add Error Logging

Some scripts fail, exit, and don’t leave a log of what happened. When you do not implement proper error handling, you will never have visibility into what went wrong.

Fix: It’s important to add strict mode to every cron script:

#!/usr/bin/env bash
set -euo pipefail

# Your script logic here

And write down important details about the execution:

LOGFILE="/var/log/cron-debug.log"

{
  echo "----- $(date) -----"
  echo "User: $(whoami)"
  echo "Running: $0"
  echo "PATH: $PATH"
} >> "$LOGFILE" 2>&1

This one change fixes most silent failures.

How CloudRay Helps You Avoid Silent Cron Failures

Cron jobs fail without anyone knowing because they were never meant to be seen, audited, or debugged. Once a job is scheduled, you have no way of knowing if it ran, failed halfway through, or never ran at all.

CloudRay has a different way of doing scheduled automation.

CloudRay lets you schedule scripts from one place instead of having to deal with crontabs on different servers. It also keeps a full history of when each script was run. You can see everything that happened when a script ran: the start time, the end time, the exit status, and the output in real time.

CloudRay’s Run Logs keep track of every scheduled run, making it easy to check on past runs, fix problems, and make sure a job really ran. You don’t have to manually send output to log files or SSH into servers to find out what went wrong.

CloudRay also fixes a lot of the common problems with cron that we talked about earlier:

Scripts run in a controlled environment for execution.
Logs are automatically saved
Failures are easy to see right away
Execution history is kept on all servers

You still write Bash scripts the same way. Instead of just hoping that a cron job worked, you can check to see if it did and know exactly what went wrong when it didn’t.

Get Started with CloudRay

What is Configuration Drift and How to Eliminate It

Thu, 25 Sep 2025 00:00:00 GMT

Infrastructure teams manage thousands of servers and applications, but keeping configurations consistent across environments becomes increasingly difficult as systems scale. Configuration drift occurs when systems gradually diverge from their intended state, creating security vulnerabilities, operational inefficiencies, and troubleshooting nightmares that consume valuable engineering time.

In this article, you’ll learn what configuration drift is, how it impacts your infrastructure operations, and proven strategies to detect, prevent, and eliminate configuration inconsistencies across your server environments.

What is configuration drift?
Common configuration drift scenarios
Causes of configuration drift
Strategies for eliminating configuration drift
Wrapping up

What is configuration drift?

Configuration drift is the gradual divergence of system configurations from their original, intended state over time. When servers, applications, or infrastructure components are initially deployed, they start with identical configurations designed to ensure consistent behaviour across environments. However, through manual changes, emergency fixes, software updates, and routine maintenance, these systems slowly develop unique configurations that no longer match the original specifications.

Understanding different approaches to managing infrastructure consistency becomes crucial for organisations experiencing drift across their server environments. The comparison between configuration management and infrastructure as code reveals various strategies for preventing and detecting configuration inconsistencies before they impact operations. Configuration drift creates operational challenges including difficult troubleshooting when identical systems behave differently, security vulnerabilities when patches are inconsistently applied, and complex compliance audits when security controls aren’t uniformly implemented.

Common configuration drift scenarios

Configuration drift shows up in predictable ways across most infrastructure environments. Knowing these common scenarios helps teams catch drift early and prevent it.

Emergency Security Patches

During a security incident, admins patch production servers individually rather than through standard processes. A database server gets a MySQL security update at 2am, while identical servers in other environments are unpatched. 6 months later, vulnerability scans show inconsistent patch levels across systems that should be the same, creating compliance gaps and attack vectors.

Performance Tuning Under Pressure

Production performance issues drive quick fixes that bypass change management. An engineer tweaks Apache config on a web server to handle traffic spikes, changes MaxRequestWorkers and KeepAliveTimeout. The fix works, but similar servers are still running default config. When load balancing sends traffic to these servers, response times are unpredictable because each server handles requests differently.

Developer Testing and Debugging

Dev teams modify production-like environments during troubleshooting sessions. A dev enables verbose logging on an app server to debug integration issues, changes database connection pool sizes, or modifies environment variables for testing. These temporary changes often become permanent when devs forget to revert them, and systems behave differently than documented.

Automated Updates with Timing

Differences in package managers and auto-update systems can cause drift when systems update at different times or encounter different dependency conflicts. Automation strategies vary across environments and systems configured for auto patching might install different package versions based on when they check for updates. A server updated on Tuesday might install a different library version than one updated on Friday, and behave slightly differently.

Manual Configuration Workarounds

Operations teams create quick fixes for recurring issues without updating standard operating procedures. When backup scripts fail due to permission issues, an admin might manually adjust file permissions or modify crontab entries. These undocumented changes solve immediate problems but create unique config that doesn’t match other systems running the same workload.

These scenarios show how drift accumulates through seemingly reasonable operational decisions. Knowing the root causes behind these patterns helps teams prevent drift instead of react to it.

Causes of configuration drift

The above scenarios show how drift happens, but understanding the underlying causes helps teams fix the root problems not just the symptoms.

No Standardized Change Management

Most organisations don’t have processes for implementing changes across environments. Teams skip formal change approval for “quick fixes” or emergency situations and make undocumented changes. Without standardized procedures each admin handles changes differently and variations accumulate over time.

Insufficient Automation Coverage

Manual configuration processes inherently introduce inconsistencies. When admins configure services, install packages or modify system settings manually, human error, and personal preference create variations. Organisations automate initial deployment but manual processes for maintenance, updates and troubleshooting.

Time Pressure and Operational Urgency

Production incidents create pressure to fix things now without following process. During outages or performance issues teams prioritize getting service back up over configuration consistency. These emergency changes often bypass documentation and change management workflows and create permanent drift.

Knowledge Gaps and Tool Limitations

Team members with different skill levels and tool preferences handle configurations differently. Some admins prefer command line tools while others use graphical interfaces and create subtle configuration differences. Many teams don’t have complete knowledge of all system dependencies and when making changes unintended side effects happen.

No Monitoring and Detection

Most environments don’t have configuration monitoring so drift accumulates undetected. Without automated tools to compare actual config to desired state teams only discover inconsistencies during troubleshooting or audits. This reactive approach means drift goes undetected for extended periods.

Now that we know the causes of drift we can implement systematic ways to eliminate existing drift and prevent future inconsistencies.

Strategies for eliminating configuration drift

Eliminating configuration drift requires systematic approaches to address existing inconsistencies and prevent future ones. These work best together not separately.

Use Configuration Management Tools

Configuration management tools like Ansible, Puppet or Chef enforce desired system states across your infrastructure. They monitor server configurations and correct deviations from defined standards automatically. When a server’s SSH config drifts from security policies, configuration management tools detect the change and fix the approved settings without human intervention.

Adopt Infrastructure as Code

Infrastructure as Code treats server configurations as code in a repository. Teams define system configurations in declarative files that can be reviewed, tested and deployed across environments. This way all infrastructure changes go through the same review process as application code, no manual modifications.

Automate Configuration Monitoring

Deploy monitoring that compares actual server configurations to approved baselines. Tools like AWS Config, Azure Policy or open-source solutions will alert the team when configurations drift from standards. This way you catch drift within hours not months and can remediate quickly before problems compound.

Standardize Change Management

Create mandatory workflows for all config changes, including emergency ones. Require documentation, approval and testing for every change, no matter the urgency. Emergency changes should include automatic tickets for post-incident review and standardization. This way even crisis driven fixes will eventually align to your organization’s standards.

Automate Routine Tasks

Replace manual config tasks with automated scripts and tools. Choose the right scripting approach depends on your team and infrastructure, but automation eliminates human error and ensures consistency across environments. Automated deployments, updates and maintenance tasks reduce the opportunities for drift causing manual interventions.

For organisations managing distributed infrastructure, centralized script management platforms like CloudRay provide unified control over configuration automation across multiple servers and environments. This approach enables teams to deploy consistent configuration scripts, monitor execution results, and maintain audit trails without manually accessing individual systems.

These strategies create a systematic defense against configuration drift and frameworks for long term infrastructure consistency. The key is to do multiple of these together not just one.

Wrapping up

Configuration drift isn’t just a technical problem — it’s a business risk that adds up over time. Every inconsistent configuration increases your attack surface, makes troubleshooting harder and wastes engineering hours that could be spent innovating instead of firefighting.

The solution isn’t perfect discipline or heroic manual effort. It’s building systems that make consistency automatic and drift impossible. Start with configuration management tools for your most critical systems, automate one task per sprint and have change workflows that work at emergency periods.

Get Started with CloudRay

How to Deploy Your VitePress Site

Wed, 17 Sep 2025 00:00:00 GMT

VitePress is a fast, lightweight static site generator powered by Vite. It’s often used for documentation websites but can be customized for many other use cases.

In this guide, we’ll walk through deploying a VitePress site to an Ubuntu server using CloudRay, a platform for managing infrastructure and running automation Bash scripts at scale. This guide assumes you already have a VitePress project created. If not, check out the VitePress Getting Started Guide to create one.

Adding Servers to CloudRay
Create a Deployment Script
Define the Variable Group
Run the Deployment Script
Next Step
Summary

Adding Servers to CloudRay

Before getting started, make sure your machine is added to a CloudRay project and connected using the CloudRay Agent.

Create a Deployment Script

Now that your machine is connected to CloudRay, let’s create a reusable Bash script to automate the deployment process. You need to follow these steps to create the script in CloudRay.

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

#!/bin/bash

# Exit on error
set -e

echo "📦 Updating system and installing dependencies..."
sudo apt update && sudo apt install -y \
    curl git nginx

echo "🧰 Installing Node.js LTS..."
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt install -y nodejs

echo "🚀 Installing global packages..."
sudo npm install -g pm2 serve

echo "📁 Cloning or updating VitePress repo..."
sudo mkdir -p /var/www
sudo chown -R "$USER":"$USER" /var/www
cd /var/www
if [ -d "{{app_name}}/.git" ]; then
  echo "🔁 Existing repo detected — fetching latest changes..."
  cd "$app_name"
  git fetch --all --prune
  git reset --hard origin/main
else
  git clone -b main "{{repo_url}}" "{{app_name}}"
  cd "{{app_name}}"
fi

echo "📦 Installing project dependencies..."
npm install

echo "🏗️ Building the VitePress site..."
npm run build

echo "📡 Serving with PM2 on port $port..."
cd .vitepress
pm2 delete "{{app_name}}" >/dev/null 2>&1 || true
pm2 start "serve -s dist -l {{port}}" --name "{{app_name}}"

# Configure PM2 to start on boot for the current user and persist the process list
sudo env PATH=$PATH pm2 startup systemd -u "$USER" --hp "$HOME" >/dev/null
pm2 save

echo "🌐 Configuring Nginx reverse proxy..."
NGINX_CONF="/etc/nginx/sites-available/{{app_name}}"
sudo tee "$NGINX_CONF" > /dev/null <<EOF
server {
    listen 80;
    server_name {{domain}};

    location / {
        proxy_pass http://localhost:{{port}};
        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

echo "🔗 Enabling Nginx config and restarting..."
sudo ln -sf "$NGINX_CONF" /etc/nginx/sites-enabled/
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl reload nginx

echo "✅ Deployment complete! Access your site at http://{{domain}}"

Here is what the Deploy VitePress Site does:

Install Node.js and dependencies
Clone your VitePress repo (or update if it exists)
Install dependencies and build the VitePress project
Serve the built files using PM2 and serve
Configure Nginx as a reverse proxy

Define the Variable Group

Now, before running the deployment script, you need to define values for the placeholders {{repo_url}}, {{port}}, {{app_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:

repo_url: The URL of your GitHub repository
app_name: Name of your VitePress app (used as directory + PM2 process name)
port: Internal port to serve your app (e.g., 3000)

Since the variables is setup, proceed with running the scripts with CloudRay

Run the Deployment Script

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

Once the script is saved, you can deploy your VitePress site by creating a Runlog:

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 “Deploy VitePress Site”
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 Deploy Vite Site, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Once the deployment is complete, you can visit http://<your-server-ip>. You should see your VitePress site up and running

Next Step

To improve your deployment and security:

You can use Let’s Encrypt to add HTTPS support
Set up automatic redeployment with webhooks or CI/cd

Summary

With CloudRay, deploying your VitePress site to Ubuntu becomes a structured and repeatable process. Scripts remain organised, server access is centralised, and you can easily tweak configurations with variable groups.

For more deployment guides and use cases, check out our CloudRay Guides or explore the CloudRay Docs.

Configuration Management vs Infrastructure as Code Explained

Sat, 06 Sep 2025 00:00:00 GMT

Managing IT infrastructure and applications is hard, especially as things scale. Two practices that help make it easier are Configuration Management (CM) and Infrastructure as Code (IaC). While they’re similar, they serve different purposes in IT ops and DevOps.

Configuration Management enforces system states automatically, while Infrastructure as Code treats infrastructure like software development. Knowing when to use each will save your team a ton of time and reduce operational complexity.

In this post we’ll go into both, the practical differences and how to choose the right one for your infrastructure.

What is Configuration Management?
- Benefits of Configuration Management
What is Infrastructure as Code (IaC)?
- Benefits of Infrastructure as Code
Differences Between IaC and Configuration Management
When to Use Each Approach
The Middle Ground: Centralised Script Management

What is Configuration Management?

Configuration Management is the practice of managing changes to a system so it stays consistent and doesn’t drift over time. It ensures servers, applications and infrastructure components stay in the desired state, automatically correcting any deviations that occur from manual changes, software updates or system failures.

Think of Configuration Management as a blueprint enforcement system. When you define how a web server should be configured, which packages are installed, what services are running, and how security is applied. CM tools monitor and enforce those specifications across all your servers.

For example, imagine you have 50 web servers that should all run the same version of Apache with the same security configuration. Without Configuration Management, updating all servers when you need to change the SSL certificate or apply a security patch is a time-consuming and error-prone process. With Configuration Management you update the configuration once and the system applies the changes across all servers.

Popular Configuration Management tools are Puppet, Chef, Ansible and SaltStack. These platforms use different approaches, Puppet uses a declarative language, Chef uses Ruby based “recipes” while Ansible uses simple YAML playbooks that don’t require agents on target machines. Some teams prefer simpler approaches using standard scripting languages, and choosing the scripting language for automation tasks often depends on your team’s expertise and infrastructure requirements.

The core principle remains the same across all tools which is define the desired state once and let the system maintain that state across your entire infrastructure.

Benefits of Configuration Management

Configuration Management offers several key benefits:

Consistency Across Environments

Configuration Management gets rid of the “works on my machine” problem by ensuring the same configuration across dev, staging and production environments. When configurations are defined as code and enforced automatically, you can be sure your production environment matches your testing environment exactly.

Reduced Configuration Drift

Systems drift from their intended state over time due to manual changes, security patches or application updates. Configuration Management monitors and corrects these deviations automatically, no human intervention required.

Faster Recovery and Scaling

When servers fail or you need to provision new infrastructure, Configuration Management allows you to deploy properly configured systems in minutes. Instead of setting up each server manually, you can spin up new instances that configure themselves according to your specs.

Audit Trail and Compliance

Every configuration change is tracked and versioned, so you can see what changed, when and who changed it. This audit capability is key for compliance and troubleshooting config issues.

Reduced Human Error

Manual config processes are error prone - typos, missed steps or inconsistent implementations. Automated config enforcement eliminates these human errors, so you get more reliable and predictable infrastructure.

What is Infrastructure as Code (IaC)?

Infrastructure as Code (IaC) is the practice of managing and provisioning your computing infrastructure through code instead of physical hardware configuration or interactive configuration tools. Instead of setting up servers, networks and storage through web consoles or command line interfaces, you write code that describes your entire infrastructure architecture.

IaC treats infrastructure like software development. You write code, version control it, test it and deploy it using automated processes. The infrastructure definitions are stored as text files that can be shared, reviewed and modified just like application code.

Consider this example, instead of logging into AWS console to manually create 10 virtual machines, configure load balancers, set up databases and establish networking rules, you write a single configuration file that describes all these resources. When you run this file through an IaC tool, it creates your entire infrastructure stack in minutes.

Leading IaC tools are Terraform, AWS CloudFormation, Azure Resource Manager and Google Cloud Deployment Manager. Terraform uses HashiCorp Configuration Language (HCL) to define infrastructure across multiple cloud providers, while cloud specific tools like CloudFormation use JSON or YAML templates to provision resources within their respective platforms.

The key difference from Configuration Management is the scope. While Configuration Management is about configuring existing systems, IaC is about creating, modifying and destroying the infrastructure itself.

Benefits of Infrastructure as Code

IaC gives you operational benefits that go beyond automation. These are especially valuable for companies managing complex infrastructure across multiple environments at scale.

Version Control and Collaboration

Infrastructure code can be stored in version control systems like Git, so teams can track changes, collaborate on infrastructure changes and roll back to previous versions when things go wrong. It brings software development best practices to infrastructure management, code reviews and change approval for infrastructure changes.

Reproducible Environments

IaC lets you spin up identical environments on demand. Whether you need to replicate production for testing, create disaster recovery environments or spin up temporary development instances, the same code produces the same results every time, no environment specific bugs and configuration drift.

Cost Management and Resource Optimisation

With IaC you can tear down and recreate environments when they’re not needed, reducing cloud costs. Development and testing environments can be destroyed at night and recreated in the morning, production environments get consistent resource allocation and optimisation.

Faster Deployment and Scaling

Infrastructure that took days or weeks to provision can be done in minutes through automated deployment pipelines. As business requirements change, scaling infrastructure up or down is as simple as modifying a few parameters in your infrastructure code and redeploy.

Documentation and Knowledge Sharing

Your infrastructure code is living documentation of your system architecture. New team members can understand the infrastructure design by reading the code and institutional knowledge is preserved when team members leave the company.

Differences Between IaC and Configuration Management

While Configuration Management and Infrastructure as Code both automate infrastructure operations, they are very different in scope, timing and implementation. Understanding the differences helps you choose the right tool for the job.

Scope and Purpose

Configuration Management is about maintaining and configuring existing infrastructure. It keeps servers that already exist in their desired state, managing software installations, service configurations and system settings. IaC is about creating and destroying infrastructure resources themselves - virtual machines, networks, storage and cloud services.

Implementation Timing

Configuration Management runs continuously after infrastructure is provisioned. It monitors systems and applies corrections when configurations drift from desired states. IaC runs during specific deployment events - when you need to create new environments, scale resources or modify infrastructure architecture.

State Management

Configuration Management uses agents or agentless connections to check current system states against desired configurations. It remediates differences automatically and continuously. IaC tools maintain state files that track which resources exist and their current configuration, and only make changes when you explicitly run deployment commands.

Learning Curve and Complexity

Configuration Management often requires learning domain-specific languages or complex frameworks. Teams need to understand concepts like manifests, playbooks or recipes. IaC tools use more familiar formats like JSON, YAML or simple declarative languages but require understanding of infrastructure architecture and cloud service relationships.

Use Case Overlap

Some scenarios blur the lines between these approaches. Tools like Terraform can provision infrastructure and do basic configuration, while Ansible can manage both infrastructure provisioning and ongoing configuration management, so modern tools are increasingly combining both capabilities.

When to Use Each Approach

Choosing between Configuration Management and Infrastructure as Code depends on your infrastructure challenges, team capabilities and operational requirements. Each approach is good for different scenarios and organisational contexts.

Use Configuration Management When:

You have existing infrastructure that needs to be maintained and configured. Configuration Management is good at managing long running servers, applying security patches consistently and maintaining compliance across distributed systems. It’s particularly useful for teams managing traditional server environments, hybrid cloud setups or infrastructure where manual configuration changes happen frequently.

Teams with limited cloud expertise but strong sysadmin skills often find Configuration Management more approachable. If your infrastructure doesn’t change often but needs ongoing maintenance, Configuration Management provides continuous oversight without the complexity of full infrastructure provisioning workflows.

Use Infrastructure as Code When:

Your infrastructure changes frequently or you need to create and destroy environments regularly. IaC is good in cloud native environments where resources are treated as disposable and environments are created on demand. It’s essential for teams doing continuous delivery, managing multiple staging environments or operating in rapidly scaling organisations.

Organisations prioritising disaster recovery, cost optimisation through environment automation or teams that need to replicate infrastructure across different cloud providers benefit from IaC approaches. The ability to version control infrastructure changes and apply software development practices to infrastructure management makes IaC particularly useful for DevOps mature organisations.

The Hybrid Reality:

Many teams use both approaches, IaC for infrastructure provisioning and Configuration Management for system maintenance. Others find success with simpler approaches, especially when starting their automation journey. Simple script automation can provide immediate value for teams not ready for complex frameworks, allowing gradual progression to more advanced infrastructure management practices.

The Middle Ground: Centralised Script Management

Between full Infrastructure as Code and traditional Configuration Management lies a middle ground, a centralised script management. This approach combines the simplicity of shell scripts with central control and monitoring.

Many teams start with scattered bash scripts across different servers, managed individually through cron jobs or manual execution. While these scripts solve immediate problems, they become hard to manage and monitor as infrastructure grows. Centralised script management solves these problems without requiring teams to learn complex frameworks or rewrite existing automation logic.

CloudRay provides a centralised platform for bash script automation across cloud and server infrastructure. Through the CloudRay Agent, teams can connect their instances and servers securely and execute scripts in real-time from a single control panel. The Schedules feature automates script execution at custom intervals—hourly, daily or event triggered—so you can have reliable DevOps workflows without manual intervention.

This is a quick win for teams not ready for complex frameworks and a clear path to more advanced infrastructure management as you grow.

Get Started with CloudRay

How to Deploy Your Jekyll Site

Thu, 28 Aug 2025 00:00:00 GMT

Jekyll is a classic static site generator built on Ruby. In this guide, you’ll deploy a Jekyll project to an Ubuntu server using CloudRay, a platform for managing servers and running automation Bash scripts at scale.

This guide assumes you already have a Jekyll project. However, if you’ve not created a Jekyll project, check out the Jekyll getting started guide to learn more and create your own.

Adding Servers to CloudRay
Create a Deployment Script
Define the Variable Group
Run the Deployment Script
Next Step
Summary

Adding Servers to CloudRay

Before getting started, make sure your machine is added to a CloudRay project and connected using the CloudRay Agent.

Create a Deployment Script

Now that your machine is connected to CloudRay, let’s create a reusable Bash script to automate the deployment process. You need to follow these steps to create the script in CloudRay.

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

#!/usr/bin/env bash
set -euo pipefail

echo "🔧 Updating system packages..."
apt-get update -y

echo "🌱 Installing dependencies (Ruby, build tools, Nginx, Git)..."
apt-get install -y ruby-full build-essential zlib1g-dev git nginx

# Optional: Remove default Nginx site
rm -f /etc/nginx/sites-enabled/default || true

# Use local gem path to avoid global installs (keeps things tidy)
export GEM_HOME="/opt/jekyll/gems"
export PATH="$GEM_HOME/bin:$PATH"
mkdir -p "$GEM_HOME"

echo "💎 Installing Jekyll and Bundler..."
gem install bundler jekyll

# Prepare workspace
WORKDIR="/opt/jekyll/src"
rm -rf "$WORKDIR"
mkdir -p "$WORKDIR"
cd "$WORKDIR"

echo "⬇️  Cloning repository..."
git clone "{{repo_url}}" "{{app_name}}"
cd "{{app_name}}"

echo "📦 Installing project gems..."
# Install gems into vendor/bundle so the build is self-contained
bundle config set path 'vendor/bundle'
bundle install

echo "🏗️ Building the Jekyll site..."
# JEKYLL_ENV=production ensures production build (e.g., minification if configured)
JEKYLL_ENV=production bundle exec jekyll build

echo "📂 Preparing deploy directory..."
mkdir -p "{{deploy_dir}}"
# Copy the generated static site
rsync -a --delete "_site/" "{{deploy_dir}}/"

echo "🧭 Writing Nginx server config..."
cat >/etc/nginx/sites-available/jekyll-site <<'NGINX_CONF'
server {
    listen 80;
    server_name {{domain}};

    root {{deploy_dir}};
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}
NGINX_CONF

ln -sfn /etc/nginx/sites-available/jekyll-site /etc/nginx/sites-enabled/jekyll-site

echo "🔁 Testing and reloading Nginx..."
nginx -t
systemctl enable --now nginx
systemctl reload nginx

echo "✅ Deployment complete. Visit: http://{{domain}}"

Here is what the Deploy Jekyll Site does:

Installs Ruby, Bundler, Jekyll, Git, and Nginx
Clones your Jekyll repo and installs its gems
Builds the site to _site/ and syncs it to {{deploy_dir}}
Creates an Nginx server block and reloads Nginx

Define the Variable Group

To make this script reusable across multiple projects or servers, you’ll define a variable group inside CloudRay. These variables dynamically fill in the placeholders like {{repo_url}}, {{app_name}}, {{deploy_dir}} and {{domain}}. CloudRay processes all scripts as Liquid templates.

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:

repo_url: The URL of your GitHub repository
app_name: Your Jekyll deployment directory
domain: This is the name of your domain, e.g., myapp.example.com
deploy_dir: Final directory Nginx will serve from (e.g., /var/www/jekyll-site)

Since the variables is setup, proceed with running the scripts with CloudRay

Run the Deployment Script

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

Once the script is saved, you can deploy your Jekyll site by creating a Runlog:

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 “Deploy Jekyll Site”
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 Deploy Jekyll Site, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Once the deployment is complete, you can visit http://<your_domain>. You should see your Jekyll site up and running

Next Step

To improve your deployment and security:

You can use Let’s Encrypt to add HTTPS support
Set up automatic redeployment with webhooks or CI/CD

Summary

With CloudRay, deploying your Jekyll site to Ubuntu becomes a structured and repeatable process. Scripts remain organised, server access is centralised, and you can easily tweak configurations with variable groups.

For more deployment guides and use cases, check out our CloudRay Guides or explore the CloudRay Docs.

Get Started with CloudRay

Bash vs Python for DevOps - Which is Better for Automation

Mon, 25 Aug 2025 00:00:00 GMT

Automation is the backbone of modern DevOps and IT operations. Choosing the right scripting language can significantly improve efficiency, scalability, and maintainability in your workflows. Bash and Python are two of the most popular choices for script automation in DevOps.

In this article, you’ll learn what each brings to the table, their strengths and weaknesses, and which to choose for your DevOps automation tasks.

What is Bash in DevOps
What is Python in DevOps
Head-to-head comparison: Bash vs Python
When to use Bash in DevOps automation
When to use Python in DevOps automation
Conclusion

What is Bash in DevOps

Bash (Bourne Again SHell) is a command line scripting language widely used in Unix and Linux based systems. In DevOps, Bash is often the first choice for automating administrative tasks, deployment processes, and system management. It lets engineers quickly automate Unix/Linux tasks using simple shell commands.

What makes Bash unique is its lightweight nature and the ability to interact directly with the operating system. Since Bash ships with most Unix/Linux systems, you can start writing automation scripts on the fly without extra setup. This makes it ideal for tasks like managing schedules, chaining multiple commands, or automating deployments.

However, Bash can become harder to maintain as scripts grow. It also lacks advanced programming features like object-oriented, making it less suitable for complex automation.

What is Python in DevOps

Python is a high‑level programming language that has become widely used in DevOps for automation tasks. Unlike Bash, which is tailored to system‑level scripting, Python is a general‑purpose language with a rich ecosystem of frameworks and libraries, making it a good choice for larger and more complex automation across multiple operating systems.

In DevOps, Python is used for configuration management, cloud automation, CI/CD pipelines, and many other tasks. With libraries such as Ansible, Fabric, and SaltStack, Python can automate server provisioning, network operations, and application deployment across environments.

What makes Python stand out is its readability, maintainability, and extensive community support. You can write scripts that are easy to understand, debug, and maintain. Additionally, Python supports advanced concepts like object‑oriented programming (OOP), error handling, and modular code.

However, Python is not as lightweight as Bash and often requires additional setup and environments to run tasks, which can be overkill for quick system‑administrative work.

Head-to-head comparison: Bash vs Python

Feature	Bash	Python
Primary use case	Best suited for script automation, task scheduling, and managing Unix/Linux operations	Best suited for complex automation, cross‑platform DevOps workflows, and integrations
Learning curve	Lightweight and easy to learn for sysadmins with Unix/Linux experience	Beginner‑friendly with readable syntax; widely adopted by developers and DevOps engineers
Platform support	Widely used in Unix/Linux systems and available by default	Cross‑platform; works well in containerised and cloud environments
Script complexity	Excellent for short, quick commands and chaining system utilities; harder to maintain for larger scripts	Handles both small and large scripts for automation projects
Error handling & debugging	Limited error handling; debugging Bash scripts can be time‑consuming	Good error handling and built‑in debugging libraries
Integration with tools	Strong integration with system utilities like `grep`, `awk`, `sed`, and package managers	Strong ecosystem of libraries such as `boto3` (AWS), `paramiko` (SSH), and `requests` (HTTP), enabling seamless integration with cloud, APIs, and automation pipelines
Performance	Very fast for small, shell‑level tasks such as process automation	Slightly slower than Bash but optimised for larger automation projects
Syntax	Shell commands; less readable	Readable, high‑level syntax
Community & support	Large community support and extensive resources available	Massive, active community; rich DevOps‑focused libraries; continuous ecosystem growth
Best fit	When speed and simplicity for system‑level tasks are priorities	When scalability and integration with modern DevOps pipelines are required

Both Bash and Python have their strengths and weaknesses, and the choice between them depends on the specific requirements of your DevOps automation tasks.

When to use Bash in DevOps automation

Bash is a great choice when simplicity and speed are required to automate DevOps workflows, especially in Unix/Linux environments. Here are scenarios where Bash shines:

Direct system‑level tasks: When you need to automate system‑level tasks like file clean‑ups, restarting services, or running immediate system checks, Bash is a good choice. You can write quick scripts without dependencies or additional setup. Since Bash is pre‑installed on most Unix/Linux systems, there are no setup delays.
CI/CD pipeline orchestration: Bash is often used in CI/CD workflows to orchestrate tasks like running tests, building applications, and deploying code. It can chain multiple commands together, making it easy to automate the pipeline. Bash integrates with tools like Jenkins, GitLab CI, and Travis CI.
Infrastructure bootstrapping: Bash can be invoked by tools like Terraform, Ansible, or CloudFormation to bootstrap and provision infrastructure. You can use Bash scripts to install dependencies, configure servers, and set up environments before deploying applications. For example, you can use Bash to automate deployment of a PostgreSQL database or deploy a SonarQube server.
Monitoring and maintenance automation: Bash excels at scheduling system checks, backups, log rotation, and other routine maintenance tasks. For example, you can use Bash to back up a WordPress site or monitor CPU and memory usage.

Generally, Bash shines when you need speed, direct system access, and minimal setup for quick system‑automation tasks.

When to use Python in DevOps automation

Python is a universal programming language and therefore can be useful for more complex DevOps workflow tasks. Here are some cases where Python is a better choice for DevOps automation:

Cloud infrastructure automation: Python is widely used for creating SDKs for major cloud providers such as AWS, Azure, and Google Cloud. For example, you can use the boto3 library to automate AWS resources such as EC2 instances, S3 buckets, or even Lambda functions. Python has extensive libraries and frameworks that allow you to interact with cloud APIs, manage resources, and automate cloud‑based workflows.
Configuration management and orchestration: The most widely used configuration managements tools like Ansible and SaltStack are built with Python. These tools allow you to define and enforce the desired state of your infrastructure, automate deployments, and bring consistency across environments. Python also integrates seamlessly with orchestration tools like Kubernetes.
Advanced scheduling: Python has libraries such as schedule and APScheduler that help with complex schedules. It also powers tools like Apache Airflow and RQ (Redis Queue) for orchestrating complex jobs. Python is used for complex and robust DevOps workflows.
Cross‑platform automation: Python is cross‑platform, so you can run scripts on Windows, macOS, and Linux. This portability makes Python a good choice for automating tasks that need to run on different platforms. For example, you can use Python to automate deployment of applications across environments.

Python is a better choice for more advanced, cross‑environment automation tasks.

Conclusion

Both Bash and Python have their place in your DevOps toolkit, but you don’t need to choose just one. The most successful DevOps teams leverage both Bash for quick system tasks and lightweight automation and Python for complex workflows and cross-platform solutions.

The real challenge isn’t choosing between Bash or Python. It’s managing, executing, and monitoring your automation scripts across multiple servers and cloud environments efficiently.

Ready to streamline your script automation? CloudRay transforms how you manage automation across your entire infrastructure. With our CloudRay Agent, you can securely execute Bash scripts from a centralised dashboard, schedule them to run automatically with CloudRay Schedules, and monitor their execution in real-time no matter if you’re managing 5 servers or 500.

Stop juggling multiple terminals and SSH connections. Start automating smarter with CloudRay’s unified platform that supports both your Bash efficiency.

Get Started with CloudRay

How to Deploy Your Eleventy Site

Thu, 14 Aug 2025 00:00:00 GMT

Eleventy is a fast, flexible static site generator written in JavaScript. It allows you to create modern, highly performant static websites using templates, Markdown, and data files. In this guide, we’ll walk you through deploying an Eleventy project to an Ubuntu server using CloudRay, a platform that helps you manage infrastructure and automate deployments with reusable Bash scripts.

This guide assumes you already have an Eleventy project set up. If not, you can clone the Eleventy Base Blog starter to get started.

Adding Servers to CloudRay
Create a Deployment Script
Define the Variable Group
Run the Deployment Script
Next Step
Summary

Adding Servers to CloudRay

Before getting started, make sure your machine is added to a CloudRay project and connected using the CloudRay Agent.

Create a Deployment Script

Now that your machine is connected to CloudRay, let’s create a reusable Bash script to automate the deployment process. You need to follow these steps to create the script in CloudRay.

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

#!/bin/bash

# Exit on error
set -e

echo "📦 Updating system and installing dependencies..."
sudo apt update && sudo apt install -y \
    curl git nginx

echo "🧰 Installing Node.js LTS..."
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt install -y nodejs

echo "🚀 Installing global packages..."
sudo npm install -g pm2 serve


echo "📁 Cloning or updating Eleventy repo..."
sudo mkdir -p /var/www
sudo chown -R "$USER":"$USER" /var/www
cd /var/www
if [ -d "{{app_name}}/.git" ]; then
  echo "🔁 Existing repo detected — fetching latest changes..."
  cd "{{app_name}}"
  git fetch --all --prune
  # Adjust branch if your default branch is not 'main'
  git reset --hard origin/main
else
  git clone "{{repo_url}}" "{{app_name}}"
  cd "{{app_name}}"
fi

echo "📦 Installing project dependencies..."
npm install

echo "🏗️ Building the Eleventy site..."
npx @11ty/eleventy

echo "📡 Serving with PM2 on port {{port}}..."
pm2 start "serve _site -l {{port}}" --name "{{app_name}}"

# Configure PM2 to start on boot for the current user and persist the process list
sudo env PATH=$PATH pm2 startup systemd -u "$USER" --hp "$HOME" >/dev/null
pm2 save

echo "🌐 Configuring Nginx reverse proxy..."
NGINX_CONF="/etc/nginx/sites-available/{{app_name}}"
sudo tee "$NGINX_CONF" > /dev/null <<EOF
server {
    listen 80;
    server_name {{domain}};

    location / {
        proxy_pass http://localhost:{{port}};
        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

echo "🔗 Enabling Nginx config and restarting..."
sudo ln -sf "$NGINX_CONF" /etc/nginx/sites-enabled/
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl reload nginx

echo "✅ Deployment complete! Access your site at http://{{domain}}"

Here is what the Deploy Eleventy Site does:

Installs system dependencies and Node.js
Clone your Eleventy project from a Git repository
Build the project
Serves the site with PM2
Sets up Nginx as a reverse proxy

Define the Variable Group

To make this script reusable across multiple projects or servers, you’ll define a variable group inside CloudRay. These variables dynamically fill in the placeholders like {{repo_url}}, {{app_name}}, {{port}} and {{domain}}. CloudRay processes all scripts as Liquid templates.

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:

repo_url: The URL of your GitHub repository
app_name: Your Eleventy deployment directory
domain: This is the name of your domain, e.g., myapp.example.com
port: The port your Eleventy application listens on (e.g., 3000)

Since the variables is setup, proceed with running the scripts with CloudRay

Run the Deployment Script

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

Once the script is saved, you can deploy your Eleventy site by creating a Runlog:

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 “Deploy Eleventy Site”
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 Deploy Eleventy Site, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Once the deployment is complete, you can visit http://<your_domain>. You should see your Eleventy site up and running

Next Step

To improve your deployment and security:

You can use Let’s Encrypt to add HTTPS support
Set up automatic redeployment with webhooks or CI/CD

Summary

With CloudRay, deploying your Eleventy site to Ubuntu becomes a structured and repeatable process. Scripts remain organised, server access is centralised, and you can easily tweak configurations with variable groups.

For more deployment guides and use cases, check out our CloudRay Guides or explore the CloudRay Docs.

Get Started with CloudRay

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

Tue, 12 Aug 2025 00:00:00 GMT

Script automation is the use of code, written in languages such as Bash or Python 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 Deploy Your Gridsome Site

Thu, 31 Jul 2025 00:00:00 GMT

Gridsome is a modern Vue-powered static site generator that helps you build fast, SEO-friendly websites using GraphQL and Vue components. In this guide, we’ll walk you through deploying a Gridsome project to an Ubuntu server using CloudRay, a platform that helps you manage your infrastructure and automate deployments using reusable Bash scripts.

This guide assumes you already have a Gridsome project set up. If not, check out the Getting Started Guide to scaffold your project.

Adding Servers to CloudRay
Create a Deployment Script
Define the Variable Group
Run the Deployment Script
Next Step
Summary

Adding Servers to CloudRay

Before getting started, make sure your machine is added to a CloudRay project and connected using the CloudRay Agent.

Create a Deployment Script

Now that your machine is connected to CloudRay, let’s create a reusable Bash script to automate the deployment process. You need to follow these steps to create the script in CloudRay.

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

#!/bin/bash

# Exit on error
set -e

echo "📦 Updating system and installing dependencies..."
sudo apt update && sudo apt install -y \
    curl git nginx build-essential make gcc g++ python3 libvips-dev

echo "🧰 Installing Node.js LTS..."
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt install -y nodejs

echo "🚀 Installing global packages..."
sudo npm install -g pm2

echo "📁 Cloning Gridsome repo..."
git clone "{{repo_url}}" "{{app_name}}"
cd "{{app_name}}"

echo "📦 Installing project dependencies..."
npm install

echo "🏗️ Building the Gridsome app..."
npm run build

echo "📡 Serving with PM2 on port $PORT..."
pm2 start "npx serve dist -l {{port}}" --name "{{app_name}}"
pm2 save
pm2 startup

echo "🌐 Configuring Nginx reverse proxy..."
NGINX_CONF="/etc/nginx/sites-available/{{app_name}}"
sudo tee "$NGINX_CONF" > /dev/null <<EOF
server {
    listen 80;
    server_name {{domain}};

    location / {
        proxy_pass http://localhost:{{port}};
        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

echo "🔗 Enabling Nginx config and restarting..."
sudo ln -sf "$NGINX_CONF" /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

echo "✅ Deployment complete! Access your site at http://{{domain}}"

Here is what the Deploy Gridsome Site does:

Installs system dependencies and Node.js
Clone your Gridsomeproject from a Git repository
Build the project
Serves the site with PM2
Sets up Nginx as a reverse proxy

Define the Variable Group

To make this script reusable across multiple projects or servers, you’ll define a variable group inside CloudRay. These variables dynamically fill in the placeholders like {{repo_url}}, {{app_name}}, {{port}} and {{domain}}. CloudRay processes all scripts as Liquid templates.

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:

repo_url: The URL of your GitHub repository
deploy_dir: Your Gridsome deployment directory
clone_dir: This is the name of the GitHub repository

Since the variables is setup, proceed with running the scripts with CloudRay

Run the Deployment Script

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

Once the script is saved, you can deploy your Gridsome site by creating a Runlog:

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 “Deploy Gridsome Site”
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 Deploy Gridsome Site, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Once the deployment is complete, you can visit http://<your_domain>. You should see your Gridsome site up and running

Next Step

To improve your deployment and security:

You can use Let’s Encrypt to add HTTPS support
Set up automatic redeployment with webhooks or CI/CD

Summary

With CloudRay, deploying your Gridsome site to Ubuntu becomes a structured and repeatable process. Scripts remain organised, server access is centralised, and you can easily tweak configurations with variable groups.

For more deployment guides and use cases, check out our CloudRay Guides or explore the CloudRay Docs.

How to Deploy Your Hexo Site

Sat, 26 Jul 2025 00:00:00 GMT

Hexo is a fast, simple, and powerful static site generator powered by Node.js. Many developers use Hexo to run personal blogs or documentation sites. In this guide, you’ll learn how to deploy your Hexo project to an Ubuntu server using CloudRay, a centralised platform that helps you automate server tasks through Bash scripting, manage infrastructure, and execute repeatable deployments.

This guide assumes you have a basic Hexo project already created. However, If you’re new to Hexo, you can follow the Hexo Getting Started Guide to scaffold your first site.

Adding Servers to CloudRay
Create a Deployment Script
Define the Variable Group
Run the Deployment Script
Next Step
Summary

Adding Servers to CloudRay

Before getting started, make sure your machine is added to a CloudRay project and connected using the CloudRay Agent.

Create a Deployment Script

Now that your machine is connected to CloudRay, let’s create a reusable Bash script to automate the deployment process. You need to follow these steps to create the script in CloudRay.

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

#!/bin/bash

# =============================
# Hexo Deployment Script
# =============================

# =============================
# 1. Install Dependencies
# =============================
sudo apt update && sudo apt install -y curl git nginx
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt install -y nodejs
sudo npm install -g pm2 serve
sudo npm install -g hexo-cli

# =============================
# 2. Clone Repo
# =============================
cd /var/www/
git clone "{{repo_url}}" "{{app_name}}"
cd "/var/www/{{app_name}}"

# =============================
# 3. Install & Build Hexo
# =============================
npm install
npx hexo generate

# =============================
# 4. Serve with PM2
# =============================
pm2 start "serve -s public -l 3000" --name hexo-site
pm2 save
pm2 startup

# =============================
# 5. Configure Nginx
# =============================
sudo bash -c "cat > /etc/nginx/sites-available/hexo-site" <<EOL
server {
    listen 80;
    server_name {{domain}};

    location / {
        proxy_pass http://localhost: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;
    }
}
EOL

sudo ln -s /etc/nginx/sites-available/hexo-site /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

# =============================
# Done!
# =============================
echo "✅ Hexo site deployed at: http://{{domain}}"

This script handles the entire process of installing dependencies, building your Hexo project, and running it behind Nginx using PM2.

Define the Variable Group

To make this script reusable across multiple projects or servers, you’ll define a variable group inside CloudRay. These variables dynamically fill in the placeholders like {{repo_url}}, {{app_name}}and {{domain}}. CloudRay processes all scripts as Liquid templates.

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:

repo_url: The URL of your GitHub repository
app_name: The name of the app folder
domain: The domain pointing to the server

Since the variables is setup, proceed with running the scripts with CloudRay

Run the Deployment Script

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

Once the script is saved, you can deploy your Hexo site by creating a Runlog:

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 “Deploy Hexo Site”
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 Deploy Hexo Site, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Once the deployment is complete, you can visit http://<your_domain>. You should see your Hexo site up and running

Next Step

To improve your deployment and security:

You can use Let’s Encrypt to add HTTPS support
Set up automatic redeployment with webhooks or CI/CD

Summary

With CloudRay, deploying your Hexo site to Ubuntu becomes a structured and repeatable process. Scripts remain organised, server access is centralised, and you can easily tweak configurations with variable groups.

For more deployment guides and use cases, check out our CloudRay Guides or explore the CloudRay Docs.

How to Deploy Your VuePress Site

Tue, 22 Jul 2025 00:00:00 GMT

VuePress is a static site generator built with Vue that’s great for technical documentation and blogs. In this guide, you’ll learn how to deploy your VuePress project to an Ubuntu server using CloudRay, a centralised platform that helps you automate server tasks through Bash scripting, manage infrastructure, and execute repeatable deployments.

This guide assumes you have a basic VuePress project already created. However, If you’re new to VuePress, you can follow the VuePress Getting Started Guide to scaffold your first site.

Adding Servers to CloudRay
Create a Deployment Script
Define the Variable Group
Run the Deployment Script
Next Step
Summary

Adding Servers to CloudRay

Before getting started, make sure your machine is added to a CloudRay project and connected using the CloudRay Agent.

Create a Deployment Script

Now that your machine is connected to CloudRay, let’s create a reusable Bash script to automate the deployment process. You need to follow these steps to create the script in CloudRay.

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

#!/bin/bash

# =============================
# VuePress Deployment Script
# =============================

set -e

# =============================
# 1. Install Dependencies
# =============================
sudo apt update && sudo apt install -y curl git nginx
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt install -y nodejs
sudo npm install -g pm2 serve

# =============================
# 2. Clone Repo
# =============================
cd /var/www/
git clone "{{repo_url}}" "{{app_name}}"
cd "/var/www/{{app_name}}"

# =============================
# 3. Build VuePress Site
# =============================
npm install
npm run build

# =============================
# 4. Serve with PM2
# =============================
cd docs/.vuepress
pm2 start "serve -s dist -l 3000" --name vuepress-site
pm2 save
pm2 startup

# =============================
# 5. Configure Nginx
# =============================
sudo bash -c "cat > /etc/nginx/sites-available/vuepress-site" <<EOL
server {
    listen 80;
    server_name {{domain_name}};

    location / {
        proxy_pass http://localhost: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;
    }
}
EOL

sudo ln -s /etc/nginx/sites-available/vuepress-site /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

# =============================
# Done!
# =============================
echo "✅ VuePress deployed at: http://{{domain_name}}"

This script handles the entire process of installing dependencies, building your VuePress project, and running it behind Nginx using PM2.

Define the Variable Group

To make this script reusable across multiple projects or servers, you’ll define a variable group inside CloudRay. These variables dynamically fill in the placeholders like {{repo_url}}, and {{domain_name}}. CloudRay processes all scripts as Liquid templates.

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:

repo_url: The URL of your GitHub repository
domain_name: The domain pointing to the server

Since the variables is setup, proceed with running the scripts with CloudRay

Run the Deployment Script

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

Once the script is saved, you can deploy your VuePress site by creating a Runlog:

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 “Deploy VuePress Site”
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 Deploy VuePress Site, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Once the deployment is complete, you can visit http://<your_domain>. You should see your VuePress site up and running

Next Step

To improve your deployment and security:

You can use Let’s Encrypt to add HTTPS support
Set up automatic redeployment with webhooks or CI/CD

Summary

With CloudRay, deploying your VuePress site to Ubuntu becomes a structured and repeatable process. Scripts remain organised, server access is centralised, and you can easily tweak configurations with variable groups.

For more deployment guides and use cases, check out our CloudRay Guides or explore the CloudRay Docs.

How to Deploy Your RedwoodJS Application

Thu, 17 Jul 2025 00:00:00 GMT

RedwoodJS is a full-stack JavaScript framework that integrates frontend and backend development into a single unified workflow. It’s designed for building and deploying modern web applications using React, GraphQL, and Prisma.

In this guide, we’ll walk through deploying a RedwoodJS application on an Ubuntu server using CloudRay. This article assumes you already have a RedwoodJS project hosted in a Git repository. If you’re just getting started with RedwoodJS, check out the Quick Start Guide to scaffold your first app.

Adding Servers to CloudRay
Create a Deployment Script
Define the Variable Group
Run the Deployment Script
Next Step
Summary

Adding Servers to CloudRay

Before getting started, make sure your machine is added to a CloudRay project and connected using the CloudRay Agent.

Create a Deployment Script

Now that your machine is connected to CloudRay, let’s create a reusable Bash script to automate the deployment process. You need to follow these steps to create the script in CloudRay.

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

#!/bin/bash

# Exit on error
set -e

# -----------------------------
# Update and install system packages
# -----------------------------
sudo apt update && sudo apt install -y curl git

# -----------------------------
# Install Corepack for Yarn
# -----------------------------
npm install -g corepack
COREPACK_ENABLE_DOWNLOAD_PROMPT=0 yarn init -2 --yes

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

# -----------------------------
# Clone RedwoodJS App
# -----------------------------
git clone {{repo_url}} redwood-app
cd redwood-app

# -----------------------------
# Install dependencies and build
# -----------------------------
yarn install
yarn rw g page home /
yarn rw build web

# Install PM2 globally
npm install -g pm2

# Start the RedwoodJS frontend (served from web/dist) on port 3000
pm2 start "serve -s web/dist -l 3000" --name redwood-frontend

# Save the PM2 process list to be resurrected on reboot
pm2 save

# Generate and configure system startup script
pm2 startup

Here is what the Deploy RedwoodJS Application script does:

Installs required dependencies (Node.js, Git, Yarn)
Clone your Astro project from a Git repository
Installs dependencies and builds the app
Serves the frontend from the web/dist directory

Define the Variable Group

Now, before running the deployment script, you need to define value for the placeholder {{repo_url}} 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:

repo_url: The URL of your GitHub repository

Since the variables is setup, proceed with running the scripts with CloudRay

Run the Deployment Script

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

Once the script is saved, you can deploy your Astro site by creating a Runlog:

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 “Deploy RedwoodJS Application”
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 Deploy RedwoodJS Application, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Once the deployment is complete, you can visit http://<your-server-ip>:3000. You should see your RedwoodJS site up and running.

Next Step

To productionise your deployment:

You can configure a Nginx reverse proxy to serve on port 80
Set up HTTPS with Let’s Encrypt

Summary

Deploying a RedwoodJS app with CloudRay streamlines server setup and project provisioning using Bash scripts and dynamic variables. You gain the ability to manage infrastructure and scale your app across environments more easily.

For more deployment guides and use cases, check out our CloudRay Guides or explore the CloudRay Docs.

How to Deploy Your Gatsby Site

Wed, 16 Jul 2025 00:00:00 GMT

Gatsby is a fast and modern React-based static site generator built for performance. In this guide, we’ll walk you through deploying a Gatsby project to an Ubuntu server using CloudRay, a centralised platform that helps you automate server tasks through Bash scripting, manage infrastructure, and execute repeatable deployments.

This guide assumes you have a basic Gatsby project already created. However, if you don’t have a Gatsby project set up yet, you can follow the Gatsby Quick Start Guide to get started.

Adding Servers to CloudRay
Create a Deployment Script
Define the Variable Group
Run the Deployment Script
Next Step
Summary

Adding Servers to CloudRay

Before getting started, make sure your machine is added to a CloudRay project and connected using the CloudRay Agent.

Create a Deployment Script

Now that your machine is connected to CloudRay, let’s create a reusable Bash script to automate the deployment process. You need to follow these steps to create the script in CloudRay.

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

#!/bin/bash

# =============================
# Gatsby Deployment Script
# =============================

set -e

# =============================
# 1. Install Dependencies
# =============================
sudo apt update && sudo apt install -y curl git nginx

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

# Install PM2 and Serve
sudo npm install -g pm2 serve

# =============================
# 2. Clone the Repository
# =============================
cd /var/www
sudo git clone "{{repo_url}}" "{{app_name}}"
cd "/var/www/{{app_name}}"

# =============================
# 3. Install and Build Gatsby App
# =============================
npm install && npm run build

# =============================
# 4. Start with PM2
# =============================
pm2 start "serve -s public -l 3000" --name "{{app_name}}"
pm2 save
pm2 startup

# =============================
# 5. Configure Nginx
# =============================
sudo bash -c "cat > /etc/nginx/sites-available/{{app_name}}" <<EOL
server {
    listen 80;
    server_name {{domain_name}};

    location / {
        proxy_pass http://localhost: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;
    }
}
EOL

# Enable Nginx site
sudo ln -sf "/etc/nginx/sites-available/{{app_name}}" "/etc/nginx/sites-enabled/{{app_name}}"
sudo nginx -t && sudo systemctl reload nginx

# =============================
# Done!
# =============================
echo "✅ Deployment complete. Visit: http://{{domain_name}}"

This script handles the entire process of installing dependencies, building your Gatsby project, and running it behind Nginx using PM2.

Define the Variable Group

To make this script reusable across multiple projects or servers, you’ll define a variable group inside CloudRay. These variables dynamically fill in the placeholders like {{repo_url}}, {{app_name}}, and {{domain_name}}. CloudRay processes all scripts as Liquid templates.

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:

repo_url: The URL of your GitHub repository
app_name: The name of the app folder
domain_name: The domain pointing to the server

Since the variables is setup, proceed with running the scripts with CloudRay

Run the Deployment Script

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

Once the script is saved, you can deploy your Gatsby site by creating a Runlog:

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 “Deploy Gatsby Site”
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 Deploy Gatsby Site, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Once the deployment is complete, you can visit http://<your_domain>. You should see your Gatsby site up and running

Next Step

To improve your deployment and security:

You can use Let’s Encrypt to add HTTPS support
Set up automatic redeployment with webhooks or CI/CD

Summary

With CloudRay, deploying your Gatsby site to Ubuntu becomes a structured and repeatable process. Scripts remain organised, server access is centralised, and you can easily tweak configurations with variable groups.

For more deployment guides and use cases, check out our CloudRay Guides or explore the CloudRay Docs.

How to Deploy Your Hugo Site

Mon, 07 Jul 2025 00:00:00 GMT

Hugo is a fast and flexible static site generator that enables developers to build modern websites quickly. In this guide, we’ll walk through how to deploy a Hugo site to an Ubuntu server using CloudRay, a centralised platform for managing infrastructure and automating deployment using Bash scripts.

This guide assumes you already have a Hugo project stored in a Git repository. If not, you can start by following Hugo’s Quick Start guide to create one.

Adding Servers to CloudRay
Create a Deployment Script
Define the Variable Group
Run the Deployment Script
Next Step
Summary

Adding Servers to CloudRay

Before getting started, make sure your machine is added to a CloudRay project and connected using the CloudRay Agent.

Create a Deployment Script

Now that your machine is connected to CloudRay, let’s create a reusable Bash script to automate the deployment process. You need to follow these steps to create the script in CloudRay.

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

#!/bin/bash

# Exit on error
set -e 

# === Commands ===
sudo apt update
sudo apt install hugo nginx git -y

sudo mkdir {{project_dir}}
cd {{project_dir}}

sudo git clone --recurse-submodules "{{repo}}" .

sudo hugo -D

sudo chown -R www-data:www-data {{project_dir}}/public

sudo tee /etc/nginx/sites-available/{{domain}} > /dev/null <<EOF
server {
    listen 80;
    server_name {{domain}} www.{{domain}};

    root {{project_dir}}/public;
    index index.html;

    access_log /var/log/nginx/{{domain}}_access.log;
    error_log /var/log/nginx/{{domain}}_error.log;

    location / {
        try_files \$uri \$uri/ =404;
    }
}
EOF

sudo ln -s /etc/nginx/sites-available/{{domain}} /etc/nginx/sites-enabled/

sudo nginx -t
sudo systemctl reload nginx

echo "✅ Hugo site deployed and available at http://${{domain}}"

Here is what the Deploy Hugo Site does:

Install Hugo, Git, and Nginx
Clone your Hugo project from a Git repository
Build the project
Configure Nginx to serve the generated site

Define the Variable Group

Now, before running the deployment script, you need to define values for the placeholders {{domain}}, {{repo}}, and {{project_dir}} 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:

domain: Your Hugo site domain name
repo: The URL of your GitHub repository
project_dir: Your Hugo deployment directory

Since the variables is setup, proceed with running the scripts with CloudRay

Run the Deployment Script

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

Once the script is saved, you can deploy your Hugo site by creating a Runlog:

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 “Deploy Hugo Site”
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 Deploy Hugo Site, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Once the deployment is complete, you can visit http://<your_domain>. You should see your Hugo site up and running.

Next Step

To improve your deployment and security:

You can use Let’s Encrypt to add HTTPS support
Set up automatic redeployment with webhooks or CI/CD

Summary

With CloudRay, deploying your Hugo site to Ubuntu becomes a structured and repeatable process. Scripts remain organised, server access is centralised, and you can easily tweak configurations with variable groups.

For more deployment guides and use cases, check out our CloudRay Guides or explore the CloudRay Docs.

How to Install Statamic on Ubuntu

Fri, 04 Jul 2025 00:00:00 GMT

Statamic is a flat‑file CMS built on Laravel that lets you publish dynamic content without a traditional database. On Ubuntu you typically install PHP, Composer, the Statamic CLI, and then configure Nginx by hand.

This guide shows how to turn that repeatable setup into a single Bash script you can run from CloudRay so every new server starts with an identical, working Statamic site.

Adding Servers to CloudRay
Create a Deployment Script
Define the Variable Group
Run the Installation Script
Next Step
Summary

Adding Servers to CloudRay

Before getting started, make sure your machine is added to a CloudRay project and connected using the CloudRay Agent.

Create a Deployment Script

Now that your machine is connected to CloudRay, let’s create a reusable Bash script to automate the installation process. You need to follow these steps to create the script in CloudRay.

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

#!/bin/bash

# === Exit on error ===
set -e

# === UPDATE SYSTEM ===
sudo apt update -y

# === CREATE USER NON-INTERACTIVELY ===
sudo useradd -m -s /bin/bash "{{username}}"
echo "{{username}}:{{password}}" | sudo chpasswd
sudo usermod -aG sudo "{{username}}"

# === TEMPORARILY ALLOW passwordLESS SUDO FOR USER ===
echo "{{username}} ALL=(ALL) NOPASSWD:ALL" | sudo tee "/etc/sudoers.d/{{username}}"
sudo chmod 0440 "/etc/sudoers.d/{{username}}"

# === EXECUTE THE REST AS THE NEW USER ===
sudo -i -u "{{username}}" bash << 'EOF'
# Configurable domain and PHP version inside user context

# === INSTALL REQUIRED PACKAGES ===
sudo apt install -y php-common php-fpm php-json php-mbstring zip unzip php-zip php-cli php-xml php-tokenizer php-curl git nginx

# === INSTALL COMPOSER ===
curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer

# === CHECK COMPOSER VERSION ===
composer --version

# === INSTALL STATAMIC CLI ===
composer global require statamic/cli

# === SET PATH MANUALLY FOR CURRENT SESSION ===
export PATH="$HOME/.config/composer/vendor/bin:$HOME/.composer/vendor/bin:$PATH"

# === VERIFY STATAMIC INSTALLATION ===
which statamic
statamic -V

# === CREATE PROJECT DIRECTORY ===
cd /var/www
sudo chown $USER:www-data /var/www

# === CREATE NEW STATAMIC SITE ===
script -q -c "statamic new --no-interaction {{domain}}"

# === PERSIST PATH FOR FUTURE SESSIONS ===
echo 'export PATH="$HOME/.config/composer/vendor/bin:$PATH"' >> ~/.bashrc
echo 'export PATH="$HOME/.composer/vendor/bin:$PATH"'       >> ~/.bashrc
EOF

# === SET CORRECT PERMISSIONS ===
sudo chmod -R 755 /var/www/{{domain}}
sudo chown -R www-data:www-data /var/www/{{domain}}
sudo chown -R www-data:www-data /var/www/{{domain}}/{storage,content,bootstrap/cache}
sudo chown -R www-data:www-data /var/www/{{domain}}/storage /var/www/{{domain}}/bootstrap/cache
sudo chmod -R ug+rw /var/www/{{domain}}/storage /var/www/{{domain}}/bootstrap/cache
sudo chown -R www-data:www-data /var/www/{{domain}}/storage /var/www/{{domain}}/bootstrap/cache

# === SETUP NGINX CONFIGURATION ===
sudo tee /etc/nginx/sites-available/{{domain}} > /dev/null << NGINX_CONF
server {
    listen 80;
    server_name {{domain}} www.{{domain}};
    root /var/www/{{domain}}/public;

    index index.html index.htm index.php;
    charset utf-8;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Content-Type-Options "nosniff";

    set \$try_location @static;

    if (\$request_method != GET) {
        set \$try_location @not_static;
    }

    if (\$args ~* "live-preview=(.*)") {
        set \$try_location @not_static;
    }

    location / {
        try_files \$uri \$try_location;
    }

    location @static {
        try_files /static\${uri}_\$args.html \$uri \$uri/ /index.php?\$args;
    }

    location @not_static {
        try_files \$uri /index.php?\$args;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    error_page 404 /index.php;

    location ~ \.php\$ {
        fastcgi_pass unix:/var/run/php/php{{php_version}}-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME \$realpath_root\$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}
NGINX_CONF

# === ENABLE SITE AND RELOAD NGINX ===
sudo ln -s /etc/nginx/sites-available/{{domain}} /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx


# === CLEANUP: Remove passwordless sudo access for security ===
sudo rm -f "/etc/sudoers.d/{{username}}"

echo "✅ Statamic site successfully installed at http://{{domain}}"

Here is what the Install Statamic Site does:

Creates a non-root user and installs PHP, Composer and the Statamic CLI
Generates a fresh Statamic site
Sets correct file ownership and writes an Nginx virtual-host file
Reloads Nginx and prints the site URL when finished

Define the Variable Group

Now, before running the deployment script, you need to define values for the placeholders {{username}}, {{password}}, {{domain}}, and {{php_version}} 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:

username: Linux user that owns the web root
password: Password for that user (used once then revoked)
domain: Public domain or IP of the site

Since the variables is setup, proceed with running the scripts with CloudRay

Run the Installation Script

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

Once the script is saved, you can install statamic by creating a Runlog:

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 “Install Statamic Site”
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 Install Statamic Site, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Once the deployment is complete, you can visit http://<your_domain>. You should see your Statamic site up and running.

Next Step

To improve your deployment and security:

You can use Let’s Encrypt to add HTTPS support
Use additional CloudRay scripts to automate database dumps, log rotation, or resource checks.

Summary

With CloudRay, automating the installation of Statamic to Ubuntu becomes a structured and repeatable process. Scripts remain organised, server access is centralised, and you can easily tweak configurations with variable groups. Storing this workflow in CloudRay means it’s versioned, reusable, and one‑click reproducible on any new Ubuntu machine.

For more installation guides and use cases, check out our CloudRay Guides or explore the CloudRay Docs.

How to Deploy Your Astro Site

Mon, 23 Jun 2025 00:00:00 GMT

Astro is a modern static site builder that enables fast, optimised frontend delivery using a component-based architecture. In this guide, we walk you through deploying an Astro project to an Ubuntu server using CloudRay, a platform for managing infrastructure and running automation Bash scripts at scale.

This guide assumes you have a basic Astro project already created. However, if you’ve not created an Astro project, checkout the Astro getting started Guide to learn more and choose from the several examples to build your own Astro project.

Adding Servers to CloudRay
Create a Deployment Script
Define the Variable Group
Run the Deployment Script
Next Step
Summary

Adding Servers to CloudRay

Before getting started, make sure your machine is added to a CloudRay project and connected using the CloudRay Agent.

Create a Deployment Script

Now that your machine is connected to CloudRay, let’s create a reusable Bash script to automate the deployment process. You need to follow these steps to create the script in CloudRay.

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

#!/bib/bash

# Exit immediately if a command exits with a non-zero status
set -e

# -----------------------------
# Install Node.js and dependencies
# -----------------------------
apt update && apt install -y curl unzip git
curl -fsSL https://deb.nodesource.com/setup_18.x | bash -
apt install -y nodejs

# -----------------------------
# Clone the Astro Project
# -----------------------------
rm -rf {{clone_dir}}
git clone {{repo_url}} {{clone_dir}}
cd {{clone_dir}}

# -----------------------------
# Build the Astro Project
# -----------------------------
npm install
npm run build

# -----------------------------
# Deploy to Target Directory
# -----------------------------
mkdir -p {{deploy_dir}}
cp -r dist/* {{deploy_dir}}

# -----------------------------
# Install and Configure Nginx
# -----------------------------
apt install -y nginx
rm -f /etc/nginx/sites-enabled/default

cat > /etc/nginx/sites-available/astro-site <<EOF
server {
    listen 80;
    server_name _;

    root {{deploy_dir}};
    index index.html;

    location / {
        try_files \$uri \$uri/ =404;
    }
}
EOF

ln -s /etc/nginx/sites-available/astro-site /etc/nginx/sites-enabled/astro-site
nginx -t && systemctl restart nginx

Here is what the Deploy Astro Site does:

Install Node.js and dependencies
Clone your Astro project from a Git repository
Build the Astro site
Copy the production files to {{deploy_dir}}
Installs and configure Nginx

Define the Variable Group

Now, before running the deployment script, you need to define values for the placeholders {{repo_url}}, {{deploy_dir}}, and {{clone_dir}} 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:

repo_url: The URL of your GitHub repository
deploy_dir: Your Astro deployment directory
clone_dir: This is the name of the GitHub repository

Since the variables is setup, proceed with running the scripts with CloudRay

Run the Deployment Script

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

Once the script is saved, you can deploy your Astro site by creating a Runlog:

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 “Deploy Astro Site”
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 Deploy Astro Site, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Once the deployment is complete, you can visit http://<your-server-ip>. You should see your Astro site up and running

Next Step

To improve your deployment and security:

You can use Let’s Encrypt to add HTTPS support
Set up automatic redeployment with webhooks or CI/cd

Summary

With CloudRay, deploying your Astro site to Ubuntu becomes a structured and repeatable process. Scripts remain organised, server access is centralised, and you can easily tweak configurations with variable groups.

For more deployment guides and use cases, check out our CloudRay Guides or explore the CloudRay Docs.

How to Install Ghost CMS on Ubuntu 24.04

Fri, 20 Jun 2025 00:00:00 GMT

Ghost CMS is a blasing fast, modern publishing platform for building professional blogs and newsletters. It’s built on Node.js and designed to be simple, secure, and extendable. In this guide, you’ll learn how to install and deploy Ghost CMS on Ubuntu 24.04 using Nginx, MySQL, and the official Ghost CLI.

For teams managing multiple servers or performing repeatable setups, CloudRay can help automate the installation and deployment of Ghost CMS using Bash scripts, without needing to SSH into each server manually.

Update the System & Create a Ghost User
Install and Configure Nginx
Install and Configure MySQL
Install Node.js and Ghost CLI
Create Ghost Directory and Install Ghost

Update the System & Create a Ghost User

To begin, update your system’s package index and create a dedicated user for managing Ghost. This helps isolate your CMS from the root user and enhances security.

Update the APT package index

sudo apt update

Create a non-root user named ghost

sudo adduser ghost

When prompted, enter a strong password and optionally fill in the user details.

Grant ghost user sudo privileges

sudo adduser ghost sudo

Verify the Java installation

su - ghost

From this point on, you will operate as the ghost user for the remainder of the installation.

Install and Configure Nginx

Ghost CMS uses Nginx as a reverse proxy to serve your site over HTTP or HTTPS.

Install Nginx

sudo apt install nginx -y

Allow Nginx through the firewall

sudo ufw allow 'Nginx Full'

Confirm Nginx is running

sudo systemctl status nginx

You should see output showing that the Nginx service is active (running)

if it’s not active and running, you can start the nginx service

sudo systemctl start nginx

Install and Configure MySQL

Ghost CMS uses MySQL to store all its content and metadata. Let’s install and set up a new database for Ghost.

Install MySQL Server

sudo apt install mysql-server -y

Access the MySQL shell

sudo mysql

Create a dedicated database and user for Ghost

CREATE USER 'ghostuser'@'localhost' IDENTIFIED BY 'your_strong_password';
CREATE DATABASE ghostdb;
GRANT ALL ON ghostdb.* TO 'ghostuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

You can replace the your_strong_password with a secure password

Looking to automate your MySQL setup? Check out this guide on automating MySQL installation in CloudRay.

Install Node.js and Ghost CLI

Ghost CMS is built on Node.js, so you’ll need to install Node and the Ghost CLI to manage your Ghost instance.

Install Node.js and npm

sudo apt install nodejs npm -y

Install Ghost CLI globally using npm

sudo npm install -g ghost-cli@latest

Verify the installation

ghost --version

This command confirms that Ghost CLI was installed correctly. You should see the version number in the output.

Create Ghost Directory and Install Ghost

Now that your environment is ready, it’s time to create a directory where Ghost will live and set the appropriate permissions.

Create the Ghost installation directory

sudo mkdir -p /var/www/ghost

Change the directory ownership to the ghost user

sudo chown ghost:ghost /var/www/ghost

Give the right permissions to the directory

sudo chmod 775 /var/www/ghost

Navigate to the Ghost directory

cd /var/www/ghost/

Install Ghost using the CLI

ghost install

The CLI will guide you through configuration steps like setting your blog URL, configuring MySQL credentials, and setting up Nginx and SSL.

If all dependencies are met, Ghost will install and start automatically.

In this case you can visit the Ghost CMS website with your domain.

Manually setting up the Ghost CMS across multiple servers can be time-consuming, especially when repeating the same steps on each server. [CloudRay] simplifies this process by allowing you to create reusable Bash scripts that can be executed remotely across your infrastructure.

With CloudRay, you can automate the entire Ghost CMS setup:

Create and configure the ghost user
Install required packages like Node.js, Nginx, and MySQL
Set up the Ghost CLI and automate the Ghost installation
Configure Nginx reverse proxy and SSL

Before you automate the installation process, connect your server to CloudRay using the CloudRay agent. This allows you to run bash scripts directly from the dashboard without SSH access.

Automate Installation of LAMP Stack on Ubuntu Using Bash Script

Thu, 19 Jun 2025 00:00:00 GMT

Setting up a LAMP stack (Linux, Apache, MySQL, PHP) on a fresh Ubuntu server is often the first step when provisioning a web server. While it’s a common task, doing it manually across multiple servers or environments is time-consuming and error-prone.

This guide shows you how to automatically install the LAMP stack on Ubuntu 24.04 using a Bash script. Whether you’re configuring a single droplet or orchestrating a fleet of cloud instances, using a shell script to automate LAMP installation simplifies the process and enforces consistency. You will learn how to run the scripts using CloudRay, a centralised platform that helps you organise, run, and manage your bash scripts more effectively.

Adding Servers to CloudRay
Creating the Automation Script
Create a Variable Group
Running the Script with CloudRay
Related Guides

Adding Servers to CloudRay

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

Creating the Automation Script

To automate this process across one or more Ubuntu servers, start by adding your LAMP Stack Installation to your CloudRay project.

Follow these steps to create the script in CloudRay:

Go to Scripts in your CloudRay project
Click New Script
Name: LAMP Stack Installation
Copy this code:

#!/bin/bash

set -e

# -------------------------
# Update and Install Apache
# -------------------------
sudo apt update
sudo apt install apache2 -y
sudo systemctl start apache2
sudo systemctl enable apache2
sudo systemctl status apache2
sudo ufw allow 80/tcp

# -------------------------
# Install and Secure MySQL
# -------------------------
sudo apt install -y mysql-server
sudo systemctl enable mysql
sudo systemctl start mysql
sudo systemctl status mysql
printf "y\n2\ny\ny\ny\ny\n" | sudo mysql_secure_installation

# -------------------------
# Configure MySQL Root User
# -------------------------
sudo mysql <<EOF
ALTER USER 'root'@'localhost' IDENTIFIED BY '{{db_password}}';
FLUSH PRIVILEGES;
EXIT
EOF

# -------------------------
# Create Database and User
# -------------------------
sudo mysql <<EOF
CREATE DATABASE {{db_name}};
CREATE USER '{{db_user}}'@'localhost' IDENTIFIED BY '{{db_password}}';
GRANT ALL PRIVILEGES ON {{db_name}}.* TO '{{db_user}}'@'localhost';
FLUSH PRIVILEGES;
EXIT
EOF

# -------------------------
# Install PHP 8.3 and Extensions
# -------------------------
sudo apt install -y php php-fpm
sudo apt install -y php-mysql php-opcache php-cli libapache2-mod-php

# -------------------------
# Start and Enable PHP 8.3 FPM
# -------------------------
sudo systemctl start php8.3-fpm
sudo systemctl enable php8.3-fpm
sudo systemctl status php8.3-fpm

# -------------------------
# Configure Apache to Use PHP 8.3 FPM
# -------------------------
sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.3-fpm
sudo systemctl restart apache2
sudo systemctl restart php8.3-fpm

# -------------------------
# Remove Default Apache Site
# -------------------------
sudo rm -rf /etc/apache2/sites-enabled/000-default.conf
sudo rm -rf /etc/apache2/sites-available/000-default.conf

# -------------------------
# Create Apache Virtual Host
# -------------------------
sudo tee /etc/apache2/sites-available/{{domain_name}}.conf > /dev/null <<EOF
<VirtualHost *:80>
ServerAdmin webmaster@{{domain_name}}
ServerName {{domain_name}}
DocumentRoot /var/www/{{domain_name}}

<Directory /var/www/{{domain_name}}>
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

<FilesMatch \.php$>
   SetHandler "proxy:unix:/var/run/php/php8.3-fpm.sock|fcgi://localhost/"
</FilesMatch>

ErrorLog \${APACHE_LOG_DIR}/{{domain_name}}_error.log
CustomLog \${APACHE_LOG_DIR}/{{domain_name}}_access.log combined
</VirtualHost>
EOF

# -------------------------
# Enable New Site
# -------------------------
sudo a2ensite {{domain_name}}.conf
sudo apache2ctl configtest

# -------------------------
# Create Web Root and Test PHP Page
# -------------------------
sudo mkdir -p /var/www/{{domain_name}}
sudo tee /var/www/{{domain_name}}/info.php > /dev/null <<EOF
<?php
phpinfo();
?>
EOF

# -------------------------
# Restart Apache
# -------------------------
sudo systemctl restart apache2

Once saved, this script will be ready to execute against any Ubuntu server you connect to CloudRay.

Create a Variable Group

To avoid hardcoding sensitive information like the database name, user, password, or domain across multiple servers, CloudRay lets you create variable groups.

This scripts use variables like {{db_name}}, {{db_user}}, {{db_password}}, and {{domain_name}} because CloudRay processes all scripts as Liquid templates. This allows you to use placeholders in your scripts, making them dynamic and reusable across different servers.

To provide values for these variables, you’ll need to create a variable group. Here’s how:

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 “New Variable Group”.
Add the following variables:

db_name: This is the name of the database
db_user: The name of the user
db_password: The password of the for the database user
domain_name: Your domain name of the LAMP stack server

Running the Script with CloudRay

Once your script is ready and saved in your CloudRay project, follow these steps to execute it on your Ubuntu server:

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 “LAMP Stack Installation”
Variable Group (optional): Select the variable group you created earlier.

Execute the Script: Click on Run Now to start the execution.

CloudRay will securely connecting to your server, executing the Bash script, and displaying real-time output logs. This allows you to monitor each step of the process and troubleshoot any issues directly from the dashboard.

Once the script completes successfully, open your browser and visit your domain to verify that Apache and PHP are working correctly.

You should see the PHP information page, which confirms that your LAMP stack was installed and configured properly.

Get Started with CloudRay

Related Guides

How to Install Elastic Stack on Ubuntu 24.10

Mon, 02 Jun 2025 00:00:00 GMT

Elastic Stack, formerly known as ELK Stack (Elasticsearch, Logstash, and Kibana), is a powerful suite of open-source tools for searching, analysing, and visualising data in real-time. This guide explain how to install and setup elastic stack on ubuntu.

For teams managing multiple servers or performing repeatable setups, CloudRay can help automate the installation of Elastic Stack using Bash scripts, without needing to SSH into each server manually.

Install Java for Elastic Stack
Install and Configure Elasticsearch
Install Logstash
Install and Configure Kibana
Install and Configure Filebeat
Automate the Installation of Elastic Stack with CloudRay

Install Java for Elastic Stack

Elastic stack requires Java component to run. Follow these steps to install Java.

Update the server’s package index

sudo apt update

Install the package to access repository over HTTPS

sudo apt install apt-transport-https -y

Install OpenJDK 11 using the APT package manager

sudo apt install openjdk-11-jdk -y

Verify the Java installation

java --version

Your output should be like

Set the JAVA_HOME environment variable

sudo nano /etc/environment

Add the following line at the end of the file:

JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64"

Save the file.

Reload the new environment variable

source /etc/environment
echo $JAVA_HOME

Install and Configure Elasticsearch

Elasticsearch is the core engine of the Elastic Stack. It provides distributed search and analytics capabilities across all types of data. Follow the steps below to install and configure Elasticsearch on your Ubuntu server.

Import the Elasticsearch GPG key

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg

Add the Elasticsearch APT repository

echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list

Update the APT package index

sudo apt update

Install Elasticsearch

sudo apt install elasticsearch -y

Start and enable the Elasticsearch service

sudo systemctl start elasticsearch
sudo systemctl enable elasticsearch

Verify that Elasticsearch is running

sudo systemctl status elasticsearch

You should see output indicating that the service is active and running.

Configure Elasticsearch

sudo nano /etc/elasticsearch/elasticsearch.yml

Inside the file, locate the network and discovery sections, then make the following changes:

Set Elasticsearch to listen on all network interfaces

network.host: 0.0.0.0

Set the discovery seed hosts to an empty array (for single-node setups)

discovery.seed_hosts: []

For basic development environments, you can disable the security layer

xpack.security.enabled: false

This is not recommended for production use.

Restart the Elasticsearch service to apply changes

sudo systemctl restart elasticsearch

Run the following command to check if the Elasticsearch instance is reachable

curl -X GET "localhost:9200"

You should receive a JSON response showing Elasticsearch version details and cluster status.

Install Logstash

Logstash is a powerful data processing pipeline that ingests, transforms, and sends data to your desired destination, typically Elasticsearch. It allows you to parse logs or structured data and filter them before storage or visualisation. Follow these steps to install and start Logstash on your Ubuntu server.

Install Logstash

sudo apt install logstash -y

Start and enable the Logstash service

sudo systemctl start logstash
sudo systemctl enable logstash

Check the Logstash service status

sudo systemctl status logstash

You should see that the Logstash service is active (running).

Install and Configure Kibana

Kibana is the visualisation layer of the Elastic Stack. It provides a web-based interface for exploring and visualising data stored in Elasticsearch. After installing Kibana, you can access dashboards, perform searches, and monitor your logs in real time. Follow the steps below to install and configure Kibana on your Ubuntu server.

Install Kibana

sudo apt install kibana -y

Start and enable the Kibana service

sudo systemctl start kibana
sudo systemctl enable kibana

Check the Kibana service status

sudo systemctl status kibana

You should see an active (running) status if the service started successfully.

Configure Kibana by opening the Kibana configuration file

sudo nano /etc/kibana/kibana.yml

Uncomment and modify the following lines to allow Kibana to bind to any interface and connect to your local Elasticsearch instance:

server.port: 5601
server.host: "0.0.0.0"
elasticsearch.hosts: ["http://localhost:9200"]

Save and close the file

Restart Kibana to apply the changes

sudo systemctl restart kibana

Adjust the firewall to open port 5601:

sudo ufw allow 5601/tcp

Once restarted, Kibana will be accessible via your server’s IP address on port 5601

http://your_server_ip:5601

Install and Configure Filebeat

Filebeat is a lightweight log shipper that forwards and centralises log data. It collects logs and forwards them to Logstash for processing or directly to Elasticsearch for indexing and visualisation in Kibana. Follow these steps to install and configure Filebeat on your Ubuntu server.

Install Filebeat from the Elastic repository:

sudo apt install filebeat -y

Configure Filebeat by editing the configuration file:

sudo nano /etc/filebeat/filebeat.yml

Comment out the Elasticsearch output section to disable direct shipping to Elasticsearch

#output.elasticsearch:
#  hosts: ["localhost:9200"]

Uncomment the Logstash output section and set it to point to your local Logstash instance

output.logstash:
  hosts: ["localhost:5044"]

Enable the system module to collect logs from the system itself

sudo filebeat modules enable system

Restart the Elasticsearch service to apply changes

sudo systemctl restart elasticsearch

initialise index management (this will temporarily enable Elasticsearch output just for the setup)

sudo filebeat setup --index-management -E output.logstash.enabled=false -E 'output.elasticsearch.hosts=["0.0.0.0:9200"]'

start and enable Filebeat to run on system boot:

sudo systemctl start filebeat
sudo systemctl enable filebeat

You can confirm that Filebeat is successfully shipping logs by checking indices in Elasticsearch

curl -XGET "localhost:9200/_cat/indices?v"

You should see indices prefixed with filebeat- in the output.

Automate the Installation of Elastic Stack with CloudRay

Manually setting up the Elastic Stack across multiple servers can be time-consuming, especially when repeating the same steps on each server. CloudRay simplifies this process by allowing you to create reusable Bash scripts that can be executed remotely across your infrastructure.

With CloudRay, you can automate the entire Elastic Stack setup — from installing Java, Elasticsearch, Logstash, Kibana, and Filebeat without logging into each server individually.

Before you automate the installation process, connect your server to CloudRay using the CloudRay agent. This allows you to run bash scripts directly from the dashboard without SSH access.

Get Started with CloudRay

How to Automate PostgreSQL Backup to Amazon S3

Mon, 26 May 2025 00:00:00 GMT

Automating PostgreSQL backups to Amazon S3 provides a reliable, scalable solution for data protection. S3’s durability and versioning capabilities make it ideal for storing critical database backups offsite.

In this article, you will learn how to setup a secure and automated backup process of your PostgreSQL database to an Amazon S3 bucket. To automate the backup process, we will use the built CloudRay’s schedule which simplifies running recurring backup script task without manual interventions.

This guide assumes you already have a PostgreSQL server up and running. If not, you can follow the setup guide on Setting Up a PostgreSQL Database

Creating Amazon S3 Bucket
Creating an IAM User
Manual Backup of PostgreSQL Database to S3
Automate and Schdule PostgreSQL Backups to Amazon S3 Using CloudRay
- Scheduling PostgreSQL Database Backup to Amazon S3 Using CloudRay
Wrapping Up
Related Guides

Creating Amazon S3 Bucket

First, you create the S3 bucket that will store the PostgreSQL backup files.

In the AWS Console, Navigate to the Amazon s3 service
Click on Create Bucket. You will see a general configurations
Provide a Provide a globally unique bucket name, such as “cloudray-postgres-backups”

Leave other options at their default values or customise as needed (e.g., enabling versioning or setting up encryption)

Click Create bucket

This bucket will serve as the storage location for your PostgreSQL backups. You will reference the created bucket name when assigning permissions to the IAM user.

Creating an IAM User

To securely upload backups to S3, it’s best practice to create a dedicated user with minimal, scoped-down permissions. First, you begin by creating an IAM group and attach an inline policy that grants access to a specific S3 bucket. Then, you create a user and assign it to that group.

Here are the steps to getting it done:

Navigate to the IAM section of the AWS Management Console
Click on User groups → Create group. Name the group (for example, “s3-backup”). Skip attaching policies for now, and proceed to the next step

Once the group is created, open it and go to the Permissions tab.

Click Add permissions → Create inline policy

Choose the JSON tab and paste the following policy, replacing your-bucket-name with the actual bucket name created earlier:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation",
                "s3:GetBucketAcl"
            ],
            "Resource": "arn:aws:s3:::your-bucket-name"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:GetObjectAcl",
                "s3:PutObjectAcl",
                "s3:ListBucketVersions",
                "s3:ListBucketMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": "arn:aws:s3:::your-bucket-name/*"
        }
    ]
}

Give your policy a name (for example s3-backup-policy) and save the policy

Navigate to Users → Create users
Set the username to backup-s3-user. Toogle on the Provide user access to the AWS Management Console - optional. Then, create a new password for the created user. Click on Next

On the permissions screen, give the user permission by selecting the group (s3-backup) in which the user would be added to

Review and create the user
Once these are done, you need the Access key and Secret key for programmatic access to AWS resources. To get this keys, go back to users, then click on the user created earlier. Click on Create access Key.

For the use case, select the Command Line Interface (CLI). Then click on Next

Finally create the access key and download the .csv files

NOTE

For detailed guidance on setting up AWS CLI credentials, refer to this AWS CLI setup guide. This should be done on the server where your PostgreSQL database is present.

Manual Backup of PostgreSQL Database to S3

Before automating the Backup process, it’s important to understand how to create and upload a PostgreSQL backup to your S3 bucket.

First, login to the PostgreSQL database:

sudo -u postgres psql

Let’s confirm the databases present:

\l

You result would be similar to the below

Next, exit from the database:

Exit;

use the pg_dump to first of all export the database into a .sql file:

pg_dump -U postgres -h localhost -d ecommerce_db > ecommerce_db_backup.sql

You will be prompted to enter your database password. This will create the ecommerce_db_backup.sql in the server.

Additionally, if you want to backup all your database present, then use the following command:

pg_dumpall -U postgres -h localhost --clean > all-databases-backup.sql

This command will backup all backup all your databases to the server.

Moving forward, before transfering the backups to S3, ensure you have AWS CLI configured. If you haven’t done that yet, run the following command:

aws configure

Here you provide:

Access Key ID
Secret Access Key
Default region (same as your S3 bucket)
Output format (e.g., json)

Next, use the AWS CLI s3 cp command to upload the backup file. For instance, let’s upload the blog_db_backup file to S3

aws s3 cp blog_db_backup.sql s3://cloudray-postgres-backups

You can verify your upload by visiting your s3 buckets and clicking on the bucket you created earlier

You can also verify the successful backup in CLI by listing the content of the bucket:

aws s3 ls s3://cloudray-postgres-backups

your output should be similar to the below:

Automate and Schdule PostgreSQL Backups to Amazon S3 Using CloudRay

Once you have manually verified your backup process, the next step is automation. This removes the need for constant manual effort and reduces the chances of human error.

CloudRay offers a flexible scheduling feature that allows you to run scripts at specified intervals. This is particularly useful for automating recurring tasks like backing up PostgreSQL databases.

If you haven’t already, go to https://app.cloudray.io and sign up for an account. Once signed in, you will have access to CloudRay’s dashboards for managing scripts and schedules. Additionally, 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.

To automate backups, first create a reusable script in CloudRay. This script will perform the backup and can be used across different schedules

Here are the steps to take:

Navigate to Scripts > New Script
Name the script: Backup Postgres Database
Paste in the following code:

#!/bin/bash

# Exit on error
set -e

# ===== Generate Timestamp =====
BACKUP_FILE="{{db_name}}_$(date +%F_%H-%M-%S)"

# ===== Security Checks =====
if [ -z "{{db_pass}}" ]; then
  echo "❌ Error: PostgreSQL password not set. Use a secure method to provide the password."
  exit 1
fi

# ===== Ensure Backup Directory Exists =====
mkdir -p "{{backup_dir}}"

# ===== Create Backup =====
echo "Creating backup of database: {{db_name}}"
if [ "{{compress}}" = true ]; then
    BACKUP_PATH="{{backup_dir}}/${BACKUP_FILE}.sql.gz"
    PGPASSWORD="{{db_pass}}" pg_dump -U "{{db_user}}" -h "{{db_host}}" -d "{{db_name}}" --clean | gzip > "$BACKUP_PATH"
else
    BACKUP_PATH="{{backup_dir}}/${BACKUP_FILE}.sql"
    PGPASSWORD="{{db_pass}}" pg_dump -U "{{db_user}}" -h "{{db_host}}" -d "{{db_name}}" --clean > "$BACKUP_PATH"
fi

# Check backup success
if [ $? -ne 0 ]; then
    echo "❌ Backup failed!"
    exit 1
fi
echo "✅ Backup created: $BACKUP_PATH"

# ===== Upload to S3 =====
echo "Uploading to S3 bucket: {{s3_bucket}}"
if [ "{{compress}}" = true ]; then
    aws s3 cp "$BACKUP_PATH" "s3://{{s3_bucket}}/${BACKUP_FILE}.sql.gz"
    aws s3 cp "$BACKUP_PATH" "s3://{{s3_bucket}}/{{s3_latest_backup}}"
else
    aws s3 cp "$BACKUP_PATH" "s3://{{s3_bucket}}/${BACKUP_FILE}.sql"
    aws s3 cp "$BACKUP_PATH" "s3://{{s3_bucket}}/latest_backup.sql"
fi

if [ $? -eq 0 ]; then
    echo "✅ Backup successfully uploaded to S3"
else
    echo "❌ Failed to upload backup to S3"
    exit 1
fi

# ===== Apply Retention Policy =====
echo "Cleaning up backups older than {{retention_days}} days..."
if [ "{{compress}}" = true ]; then
    find "{{backup_dir}}" -type f -name "*.sql.gz" -mtime +"{{retention_days}}" -delete
else
    find "{{backup_dir}}" -type f -name "*.sql" -mtime +"{{retention_days}}" -delete
fi

echo "✨ Backup process completed successfully"

Here is what this script does:

Creates a timestamp for PostgreSQL backup
Secures the Database access
Automate S3 upload of the backups
Manages local storage by the implementation of retention policy
Provides a clear status updates on the backup process

Next, before running the scripts, you need to define values for the placeholders {{db_user}}, {{db_pass}}, {{db_name}}, {{backup_dir}}, {{s3_bucket}}, {{retention_days}}, and {{s3_latest_backup}} 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 of the database
db_user: The name of the user
db_pass: The password of the for the database user
backup_dir: The directory where PostgreSQL database backups will be stored
s3_bucket: This is the name of the s3 bucket where the backups will be saved
retention_days: The timeframe for the backup to be deleted on the server
s3_latest_backup: The latest backup in s3 bucket

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

To run the Backup Postgres Database, 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 “Backup Postgres Database”
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 Backup Postgres Database, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

To comfirm successful backup to Amazon S3, check your S3 bucket.

Scheduling PostgreSQL Database Backup to Amazon S3 Using CloudRay

CloudRay also offers Schedules, allowing you to execute scripts automatically at specific intervals or times. This feature is useful for tasks such as automating database backups.

For example, if you want to back up your PostgreSQL database to S3 on monday of every week at 1:00 AM, you can configure a CloudRay schedule to handle this automatically.

Here are the steps to achieve this:

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 database is regularly backed up to your S3 bucket without manual intervention.

Wrapping Up

Automating PostgreSQL backups to Amazon S3 ensures your data is consistently protected, versioned, and stored offsite with minimal manual effort. By combining AWS services with CloudRay’s powerful scripting and scheduling tools, you can create a reliable and reusable backup workflow. Whether you’re managing a single database or multiple servers, this setup offers flexibility, scalability, and peace of mind.

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

Related Guides

How to Automate MySQL Backup to Amazon S3

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

Fri, 23 May 2025 00:00:00 GMT

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
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 should look similar to the output 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 manage your bash scripts in a centralised platform.

How to Automate MySQL Backup to Amazon S3

Mon, 19 May 2025 00:00:00 GMT

Automating MySQL backups and storing them on Amazon S3 is a practical way to ensure your data is safe, retrievable, and versioned offsite. S3 provides scalable, durable storage, making it an excellent choice for backup solutions.

In this article, you will learn how to setup a secure and automated backup process of your MySQL database to an Amazon S3 bucket. To automate the backup process, we will use the built CloudRay’s schedule which simplifies running recurring backup script task without manual interventions.

This guide assumes you already have a MySQL server up and running. If not, you can follow the setup guide on How to Deploy MySQL Server.

Creating Amazon S3 Bucket
Creating an IAM User
Manual Backup of MySQL Database to S3
Automate and Schdule MySQL Backups to Amazon S3 Using CloudRay
- Scheduling MySQL Database Backup to Amazon S3 Using CloudRay
Wrapping Up

Creating Amazon S3 Bucket

First, you create the S3 bucket that will store the MySQL backup files.

In the AWS Console, Navigate to the Amazon s3 service
Click on Create Bucket. You will see a general configurations
Provide a Provide a globally unique bucket name, such as “cloudray-mysql-backups”

Leave other options at their default values or customise as needed (e.g., enabling versioning or setting up encryption)

Click Create bucket

This bucket will serve as the storage location for your MySQL backups. You will reference the created bucket name when assigning permissions to the IAM user.

Creating an IAM User

Here are the steps od getting it down:

Navigate to the IAM section of the AWS Management Console
Click on User groups → Create group. Name the group (for example, “s3-backup”). Skip attaching policies for now, and proceed to the next step

Once the group is created, open it and go to the Permissions tab.

Click Add permissions → Create inline policy

Choose the JSON tab and paste the following policy, replacing your-bucket-name with the actual bucket name created earlier:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation",
                "s3:GetBucketAcl"
            ],
            "Resource": "arn:aws:s3:::your-bucket-name"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:GetObjectAcl",
                "s3:PutObjectAcl",
                "s3:ListBucketVersions",
                "s3:ListBucketMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": "arn:aws:s3:::your-bucket-name/*"
        }
    ]
}

Give your policy a name (for example s3-backup-policy) and save the policy

Navigate to Users → Create users
Set the username to backup-s3-user. Toogle on the Provide user access to the AWS Management Console - optional. Then, create a new password for the created user. Click on Next

On the permissions screen, give the user permission by selecting the group (s3-backup) in which the user would be added to

Review and create the user
Once these are done, you need the Access key and Secret key for programmatic access to AWS resources. To get this keys, go back to users, then click on the user created earlier. Click on Create access Key.

For the use case, select the Command Line Interface (CLI). Then click on Next

Finally create the access key and download the .csv files

NOTE

For detailed guidance on setting up AWS CLI credentials, refer to this AWS CLI setup guide. This should be done on the server where your MySQL database is present.

Manual Backup of MySQL Database to S3

Before automating the Backup process, it’s important to understand how to create and upload a MySQL backup to your S3 bucket.

First, login to the MySQL database:

mysql -u root -p

Let’s confirm the databases present:

SHOW DATABASES;

You result would be similar to the below

Next, exit from the database:

Exit;

use the mysqldump to first of all export the database into a .sql file:

mysqldump -u root -p blog_db > blog_db_backup.sql

You will be prompted to enter your database password. This will create the blog_db_backup.sql in the server.

Additionally, if you want to backup all your database present, then use the following command:

mysqldump -u root -p --all-databases > all-databases-backup.sql

This command will backup all backup all your databases to the server.

Moving forward, before transfering the backups to S3, ensure you have AWS CLI configured. If you haven’t done that yet, run the following command:

aws configure

Here you provide:

Access Key ID
Secret Access Key
Default region (same as your S3 bucket)
Output format (e.g., json)

Next, use the AWS CLI s3 cp command to upload the backup file. For instance, let’s upload the blog_db_backup file to S3

aws s3 cp blog_db_backup.sql s3://cloudray-mysql-backups

You can verify your upload by visiting your s3 buckets and clicking on the bucket you created earlier

You can also verify the successful backup in CLI by listing the content of the bucket:

aws s3 ls s3://cloudray-mysql-backups

your output should be similar to the below:

Automate and Schdule MySQL Backups to Amazon S3 Using CloudRay

Once you have manually verified your backup process, the next step is automation. This removes the need for constant manual effort and reduces the chances of human error.

CloudRay offers a flexible scheduling feature that allows you to run scripts at specified intervals. This is particularly useful for automating recurring tasks like backing up MySQL databases.

To automate backups, first create a reusable script in CloudRay. This script will perform the backup and can be used across different schedules

Here are the steps to take:

Navigate to Scripts > New Script
Name the script: Backup MySQL Database
Paste in the following code:

#!/bin/bash

# Exit on error
set -e


# ===== Generate Timestamp =====
BACKUP_FILE="{{db_name}}_$(date +%F_%H-%M-%S)"

# ===== Security Checks =====
if [ -z {{db_pass}} ]; then
  echo "❌ Error: MySQL password not set. Use a secure method to provide the password."
  exit 1
fi

# ===== Ensure Backup Directory Exists =====
mkdir -p {{backup_dir}}

# ===== Create Backup =====
echo "Creating backup of database: {{db_name}}"
if [ {{compress}} = true ]; then
    BACKUP_PATH="{{backup_dir}}/${BACKUP_FILE}.sql.gz"
    mysqldump --user={{db_user}} --password={{db_pass}} --single-transaction --quick {{db_name}} | gzip > "$BACKUP_PATH"
else
    BACKUP_PATH="{{backup_dir}}/${BACKUP_FILE}.sql"
    mysqldump --user={{db_user}} --password={{db_pass}} --single-transaction --quick {{db_name}} > "$BACKUP_PATH"
fi

# Check backup success
if [ $? -ne 0 ]; then
    echo "❌ Backup failed!"
    exit 1
fi
echo "✅ Backup created: $BACKUP_PATH"

# ===== Upload to S3 =====
echo "Uploading to S3 bucket: {{s3_bucket}}"
if [ {{compress}} = true ]; then
    aws s3 cp "$BACKUP_PATH" "s3://{{s3_bucket}}/${BACKUP_FILE}.sql.gz"
    aws s3 cp "$BACKUP_PATH" "s3://{{s3_bucket}}/{{s3_latest_backup}}"
else
    aws s3 cp "$BACKUP_PATH" "s3://{{s3_bucket}}/${BACKUP_FILE}.sql"
    aws s3 cp "$BACKUP_PATH" "s3://{{s3_bucket}}/latest_backup.sql"
fi

if [ $? -eq 0 ]; then
    echo "✅ Backup successfully uploaded to S3"
else
    echo "❌ Failed to upload backup to S3"
    exit 1
fi

# ===== Apply Retention Policy =====
echo "Cleaning up backups older than {{retention_days}} days..."
if [ {{compress}} = true ]; then
    find {{backup_dir}} -type f -name "*.sql.gz" -mtime +{{retention_days}} -delete
else
    find {{backup_dir}} -type f -name "*.sql" -mtime +{{retention_days}} -delete
fi

echo "✨ Backup process completed successfully"

Here is what this script does:

Creates a timestamp MySQL backup
Secures the Database access
Automate S3 upload of the backups
Manages local storage by the implementation of retention policy
Provides a clear status updates on the backup process

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 of the database
db_user: The name of the user
db_pass: The password of the for the database user
backup_dir: The directory where MySQL database backups will be stored
s3_bucket: This is the name of the s3 bucket where the backups will be saved
retention_days: The timeframe for the backup to be deleted on the server
s3_latest_backup: The latest backup in s3 bucket

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

To run the Backup MySQL Database, 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 “Backup MySQL Database”
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 Backup MySQL Database, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

To comfirm successful backup to Amazon S3, check your S3 bucket.

Scheduling MySQL Database Backup to Amazon S3 Using CloudRay

CloudRay also offers Schedules, allowing you to execute scripts automatically at specific intervals or times. This feature is useful for tasks such as automating database backups.

For example, if you want to back up your MySQL database to S3 on monday of every week at 1:00 AM, you can configure a CloudRay schedule to handle this automatically.

Here are the steps to achieve this:

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 database is regularly backed up to your S3 bucket without manual intervention.

Wrapping Up

Automating MySQL backups to Amazon S3 ensures your data is consistently protected, versioned, and stored offsite with minimal manual effort. By combining AWS services with CloudRay’s powerful scripting and scheduling tools, you can create a reliable and reusable backup workflow. Whether you’re managing a single database or multiple servers, this setup offers flexibility, scalability, and peace of mind.

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

Automate the Installation of Prometheus

Tue, 13 May 2025 00:00:00 GMT

Prometheus requires proper configuration of storage paths, user permissions, and network access to function as an effective monitoring solution. This guide demonstrates how to automate Prometheus installation with CloudRay, implementing secure service configuration, proper file permissions, and systemd service management.

Adding Servers to CloudRay
Create the Automation Script
- Prometheus Installation Script
- Prometheus Service Script
Create a Variable Group
Running the Scripts to Install Prometheus with CloudRay

Adding Servers to CloudRay

Before beginning Prometheus deployment, ensure your target servers are connected to CloudRay. If you haven’t done this yet, follow our servers docs to add and manage your server

NOTE

These scripts target Ubuntu/Debian systems. For RHEL-based distributions, replace apt commands with appropriate yum or dnf equivalents. The Prometheus configuration directory path is consistent across Linux distributions

Create the Automation Script

Two Bash scripts are required for complete Prometheus deployment:

Prometheus Installation Script: This script handles binary installation and filesystem setup
Prometheus Service Script: This script configures systemd service and runtime parameters

Prometheus Installation Script

This script performs the initial Prometheus deployment with production-ready defaults:

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

#!/bin/bash

# Exit immediately on error
set -e

# Update package list
sudo apt update

# Download Prometheus tarball
wget https://github.com/prometheus/prometheus/releases/download/v{{prom_version}}/prometheus-{{prom_version}}.linux-amd64.tar.gz

# Extract the tarball
tar xvf prometheus-{{prom_version}}.linux-amd64.tar.gz

# Move Prometheus binaries
sudo mv prometheus-{{prom_version}}.linux-amd64/prometheus /usr/local/bin/
sudo mv prometheus-{{prom_version}}.linux-amd64/promtool /usr/local/bin/

# Create Prometheus directories
sudo mkdir -p /etc/prometheus
sudo mkdir -p /var/lib/prometheus

# Move config files
sudo mv prometheus-{{prom_version}}.linux-amd64/prometheus.yml /etc/prometheus/prometheus.yml

# Show installed versions
prometheus --version
promtool --version

# Create Prometheus user and group
sudo groupadd --system {{prom_group}}
sudo useradd -s /sbin/nologin --system -g {{prom_group}} {{prom_user}}

# Set permissions
sudo chown -R {{prom_user}}:{{prom_group}} /etc/prometheus /var/lib/prometheus
sudo chmod -R 775 /etc/prometheus /var/lib/prometheus

Here is a breakdown of what the Prometheus Installation Script does:

Downloads specified Prometheus version
Installs binaries to /usr/local/bin
Creates dedicated system user and group
Sets secure directory permissions

Prometheus Service Script

This script configures Prometheus as a systemd service:

Go to Scripts > New Script
Name: Prometheus Service Script
Add code:

#!/bin/bash

# Exit immediately on error
set -e

# Create systemd service file
sudo bash -c "cat > /etc/systemd/system/prometheus.service" <<EOL
[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User={{prom_user}}
Group={{prom_group}}
Restart=always
Type=simple
ExecStart=/usr/local/bin/prometheus \\
    --config.file=/etc/prometheus/prometheus.yml \\
    --storage.tsdb.path=/var/lib/prometheus/ \\
    --web.console.templates=/etc/prometheus/consoles \\
    --web.console.libraries=/etc/prometheus/console_libraries \\
    --web.listen-address=0.0.0.0:9090

[Install]
WantedBy=multi-user.target
EOL

# Reload systemd daemon configs
sudo systemctl daemon-reload

# Start and enable Prometheus service
sudo systemctl start prometheus
sudo systemctl enable prometheus

# Show service status
sudo systemctl status prometheus --no-pager

echo "✅ Prometheus service created and started."

This is what the Prometheus Service Script does:

Systemd service unit with automatic restart
Proper user/group context
Standard data storage locations
Network binding on port 9090

Create a Variable Group

Now, before running the scripts, you need to define values for the placeholders {{prom_version}}, {{prom_user}}, and {{prom_group}}, 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:

prom_version: Prometheus release version
prom_user: System user for Prometheus
prom_group: System group for Prometheus

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

Running the Scripts to Install Prometheus with CloudRay

Now that everything is setup, you can use CloudRay to automate the installation of prometheus.

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 Prometheus Installation”)
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 Prometheus will be installed (For example “prom-server”)
Script Playlist: Choose the playlist you created (For example “Automate Prometheus Installation”)
Variable Group: Select the variable group you set up earlier

Execute the Script: Click on Run Now to start the execution

Once the script runs successfully, your Prometheus will be fully installed. You can now visit your Prometheus using your server IP on port 9090 (server-IP:9090).

This show that Prometheus is working successfully.

Get Started with CloudRay

How to Automate Grafana Installation with Nginx

Mon, 12 May 2025 00:00:00 GMT

This guide demonstrates how to automate Grafana deployments using CloudRay’s script automation. The deployment addresses these core requirements:

Secure default configuration with disabled anonymous access
Nginx reverse proxy configuration
Service isolation with proper systemd management

The approach prevents common security issues by disabling anonymous access by default, using reverse proxy for additional security layer, and implementing proper service management.

Adding Servers to CloudRay
Create the Automation Script
- Install Grafana and Nginx
- Configure Grafana
Running the Scripts to Install Grafana with CloudRay

Adding Servers to CloudRay

Before starting automation, ensure your target servers are connected to CloudRay. If you haven’t done this yet, follow our servers docs 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 Installations needs and environment. Additionally, if you’re using a different version or a different distribution, adjust the commands accordingly

Create the Automation Script

Two Bash scripts are required for deployment:

Install Grafana and Nginx: This script handles package installation and base configuration
Configure Grafana: This script applies security settings and service configuration

Install Grafana and Nginx

This script performs the initial server setup including package installation and reverse proxy configuration.

Go to Scripts in your CloudRay project
Click New Script
Name: Install Grafana and Nginx
Copy this code:

#!/bin/bash

# Exit immediately if a command exits with a non-zero status
set -e

# Update package list
sudo apt update

# Install required dependencies
sudo apt-get install -y gnupg2 curl software-properties-common

# Add Grafana GPG key
curl https://packages.grafana.com/gpg.key | sudo apt-key add -

# Add Grafana repository
printf '\n' | sudo add-apt-repository "deb https://packages.grafana.com/oss/deb stable main"

# Update package list again
sudo apt update

# Install Grafana
sudo apt -y install grafana

# Start and enable Grafana service
sudo systemctl start grafana-server
sudo systemctl enable grafana-server
sudo systemctl status grafana-server --no-pager

# Install Nginx
sudo apt install -y nginx

# Start and enable Nginx service
sudo systemctl start nginx
sudo systemctl enable nginx
sudo systemctl status nginx --no-pager

# Remove default Nginx site
sudo unlink /etc/nginx/sites-enabled/default

# Create Grafana Nginx config
sudo bash -c "cat > /etc/nginx/sites-available/grafana.conf" <<EOL
server {
    listen 80;
    location / {
        proxy_pass http://localhost:3000;
    }
}
EOL

# Enable the Grafana Nginx site
sudo ln -s /etc/nginx/sites-available/grafana.conf /etc/nginx/sites-enabled/grafana.conf

# Test Nginx configuration
sudo service nginx configtest

# Restart Nginx
sudo systemctl restart nginx

echo "✅ Grafana and Nginx installation completed."

Here is a breakdown of what each command in the Install Grafana and Nginx script does:

Updates all installed packages to the latest version
Adds official Grafana repository
Installs Grafana and Nginx
Configures Nginx as reverse proxy on port 80
Validates Nginx configuration before restarting

Configure Grafana

This script applies security-focused configuration to the Grafana installation.

Go to Scripts > New Script
Name: Configure Grafana
Add code:

#!/bin/bash

# Exit immediately if a command exits with a non-zero status
set -e

# Update grafana.ini settings
sudo sed -i 's/;allow_sign_up = true/allow_sign_up = true/' /etc/grafana/grafana.ini
sudo sed -i 's/;enabled = false/enabled = false/' /etc/grafana/grafana.ini

# Restart Grafana to apply changes
sudo systemctl restart grafana-server
sudo systemctl status grafana-server --no-pager

echo "✅ Grafana configuration updated successfully."

This is what the Configure Grafana does:

Disables anonymous access by default
Restricts sign-ups (to be enabled per requirement)
Ensures changes are applied with service restart

Running the Scripts to Install Grafana with CloudRay

Now that everything is setup, you can use CloudRay to automate the installation of Grafana.

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 Grafana Installation”)
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 Grafana will be installed
Script Playlist: Choose the playlist you created (For example “Automate Grafana Installation”)
Variable Group: Select the variable group you set up earlier

Execute the Script: Click on Run Now to start the execution

Once the script runs successfully, your Grafana will be fully deployed. You can now visit your Grafana using your domain on port 3000 (http://SERVER_IP:3000).

Your Grafana is now deployed and managed with CloudRay. You use the username admin and password admin to access your dashboard. It’s best practice to reconfigure the default credentials (username and password).

Get Started with CloudRay

How to Configure and Setup AWS CLI and Key Pairs

Thu, 01 May 2025 00:00:00 GMT

Automating AWS infrastructure requires proper setup of the AWS Command Line Interface (CLI), secure key management, and an understanding of core components like AMIs. This guide walks through configuring the AWS CLI and generating and managing EC2 key pairs.

Installing the AWS CLI
- Linux/macOS installation
- Windows installation
Configuring AWS CLI
Managing EC2 Key pairs

Installing the AWS CLI

The AWS CLI is the primary tool for interacting with AWS services programmatically. Below are installation instructions for different operating systems.

Linux/macOS installation

Install unzip(if not installed) and download the latest AWS CLI version:

sudo apt install unzip
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

Extract the packages:

unzip awscliv2.zip

Run the installer with sudo:

sudo ./aws/install

Verify the installation:

aws --version

Your expected output should look like this:

aws-cli/2.27.4 Python/3.13.2 Linux/6.11.0-9-generic exe/x86_64.ubuntu.24

Windows installation

Download the AWS CLI MSI installer.
Run the installer and follow the prompts.
Open PowerShell and verify installation:

aws --version

Alternatively, you can use a preconfigured CloudRay automation script to install and configure the AWS CLI across multiple environments for consistency.

Configuring AWS CLI

Before using the AWS CLI, you need to configure authentication credentials.

Login to the AWS IAM Console
Navigate to Users → Select your IAM user → Security credentials.

Under Access keys, click Create access key.
Choose CLI (Command Line Interface) as the use case and click Next.

You can give your access key tag (optional) and click “create access key”

You can copy the access and secret access key on the AWS console

Additionally, you can download the .csv file or copy the keys manually

Run the configuration wizard:

aws configure

You will be prompted for:

AWS Access Key ID - A unique identifier for your IAM user
AWS Secret Access Key - A secret password tied to your access key
Default region name - The AWS region where resources will be created (e.g., us-east-1)
Default output format - How responses are displayed (json, text, or table)

Verify that the CLI can authentication with AWS:

aws sts get-caller-identity

A successful response includes your AWS account ID and IAM user ARN.

Managing EC2 Key pairs

SSH key pairs are essential for secure access to your EC2 instances. This section covers creating, managing, and using key pairs with AWS CLI. Here is how to create a new key pair using AWS CLI:

First, generate a key pair using AWS CLI:

aws ec2 create-key-pair \
    --key-name "my-production-key" \
    --key-type ed25519 \
    --query 'KeyMaterial' \
    --output text > my-production-key.pem

Set proper file permissions:

chmod 400 my-production-key.pem

Here are what all the key parameters represents:

--key-name: Unique identifier for your key
--key-type: Choose between rsa (default) or more secure ed25519
KeyMaterial: The private key content (saved to .pem file)

Additionally, here is how to list all available key pairs in your region:

aws ec2 describe-key-pairs \
    --query 'KeyPairs[*].KeyName' \
    --output table

This shows the keys present in your AWS user account

Finally, here is how to delete a key pair:

First, verify no instances are using the key:

aws ec2 describe-instances \
    --filters "Name=key-name,Values=my-production-key" \
    --query "Reservations[].Instances[].InstanceId"

Delete the key pair:

aws ec2 delete-key-pair --key-name "my-production-key"

NOTE

You can locate Amazon Machine Images (AMIs) in the EC2 Console under AMIs in the left navigation. Use the search filters to find official AWS-provided images or community AMIs. For production environments, always verify AMI sources and use the most recent stable versions.

While manual AWS CLI configuration works for individual setups, managing infrastructure at scale requires automation. CloudRay provides centralised management for Bash scripts, enabling teams to securely automate and schedule AWS operations like instance provisioning, key rotation, and infrastructure monitoring.

For a practical implementation of these concepts, see our guide on Automating AWS Infrastructure with Bash and CLI which covers EC2 lifecycle management, automated backups, and monitoring solutions.

Automate the Installation of FTP Server

Wed, 30 Apr 2025 00:00:00 GMT

This guide covers the automated deployment of vsftpd (Very Secure FTP Daemon) using CloudRay scripting capabilities. This implementation ensures secure, consistent file transfer services with built-in user isolation and SSL encryption.

CloudRay’s Bash scripting engine handles the entire deployment lifecycle from package installation to firewall configuration while maintaining compliance with security best practices.

Adding Servers to CloudRay
Create the Automation Script
- FTP Server Installation Script
- FTP Configuration Script
Create a Variable Group
Running the Scripts with CloudRay
- Running FTP Server Installation Script
- Running the Deploy WordPress Script

Adding Servers to CloudRay

Before getting started with your automation, 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

NOTE

Create the Automation Script

To automate the installation of FTP Server, you will need two Bash scripts:

FTP Server Installation: This script handles the core vsftpd installation and user provisioning
FTP Configuration Script: This script implements security hardening and shared storage

Let’s begin with the installation of FTP server.

FTP Server Installation Script

To create the FTP Server Installation Script, you need to follow these steps:

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

#!/bin/bash

# Exit on error
set -e

echo "🛠️ Starting FTP server base installation..."

# Update system and install vsftpd
sudo apt update
sudo apt install vsftpd lftp -y  # lftp included for testing

# Start and enable service
sudo systemctl start vsftpd
sudo systemctl enable vsftpd

# Configure SSL (only if not already configured)
if [ ! -f /etc/ssl/private/vsftpd.pem ]; then
    echo "🔐 Generating SSL certificate..."
    sudo mkdir -p /etc/ssl/private
    sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
        -keyout /etc/ssl/private/vsftpd.pem \
        -out /etc/ssl/private/vsftpd.pem \
        -subj "/C=US/ST=California/L=San Francisco/O=My Company/OU=IT/CN=ftp.server.com"
    sudo chmod 600 /etc/ssl/private/vsftpd.pem
    echo "✅ SSL certificate created"
else
    echo "ℹ️ SSL certificate already exists - skipping generation"
fi

# Backup original config
sudo cp /etc/vsftpd.conf /etc/vsftpd.conf.bak

# Configure vsftpd with user whitelisting
sudo bash -c 'cat > /etc/vsftpd.conf <<EOF
listen=NO
listen_ipv6=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
chroot_local_user=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
ssl_enable=YES
user_sub_token=\$USER
local_root=/home/\$USER/ftp
pasv_min_port=30000
pasv_max_port=31000
userlist_enable=YES
userlist_file=/etc/vsftpd.userlist
userlist_deny=NO
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
EOF'

# Restart service
sudo systemctl restart vsftpd

# Configure firewall
sudo ufw allow ssh
sudo ufw allow 20,21,990/tcp
sudo ufw allow 30000:31000/tcp
echo "y" | sudo ufw enable

Here is a breakdown of what the FTP Server Installation Script does:

Updates all installed packages to the latest version
Installs vsftpd with TLS/SSL support
Generates SSL certificates automatically
Enforces FTPS (FTP over SSL/TLS)

FTP Configuration Script

Next, you need to configure users and give the users the necessary permissions. To do so, follow similar steps as the above:

Go to Scripts > New Script
Name: FTP Configuration Script
Add code:

#!/bin/bash

# Exit on error
set -e

# Create FTP user
sudo adduser --disabled-password --gecos "" "{{ftp_user}}"
echo "{{ftp_user}}:{{ftp_pass}}" | sudo chpasswd

# Setup directory structure
sudo mkdir -p "/home/{{ftp_user}}/ftp/upload"
sudo chown nobody:nogroup "/home/{{ftp_user}}/ftp"
sudo chmod a-w "/home/{{ftp_user}}/ftp"
sudo chown "{{ftp_user}}:{{ftp_user}}" "/home/{{ftp_user}}/ftp/upload"

# Update userlist
sudo touch /etc/vsftpd.userlist
grep -qxF "{{ftp_user}}" /etc/vsftpd.userlist || echo "{{ftp_user}}" | sudo tee -a /etc/vsftpd.userlist

echo "{{ftp_user}}" | sudo tee -a /etc/vsftpd.userlist

echo "FTP configuration for user '{{ftp_user}}' completed successfully!"

This is what the FTP Configuration Script does:

Creates chroot-jailed users from variables
Prepares directory structure with proper permissions
Configures passive mode port range
Implements user whitelisting

Create a Variable Group

Now, before running the scripts, you need to define values for the placeholders {{ftp_user}} and {{ftp_pass}} 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:

ftp_user: The FTP user
ftp_pass: The user password

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

Running the Scripts with CloudRay

The FTP server deployment follows a two-phase approach that separates infrastructure setup from user management. This modular design allows for efficient scaling and maintenance. You run the FTP Server Installation once per server to install the FTP server. Then you run the FTP Configuration Script separately to configure and configure each users on the FTP server.

Running FTP Server Installation Script

Follow these steps:

Navigate to Runlogs in your CloudRay project
Click New Run a Script

Configure the runlog:
- Server: Select your target server
- Script: Choose “FTP Server Installation”
- Variable Group: Select the variable group you created earlier
Run the script: Click on “Run” to execute the script on your server

CloudRay will connect to your server, run the FTP Server Installation script, and show you the live output as the script executes. This one-time setup installs all required system packages and services. You only need to run this script once when setting up a new server and install FTP.

Running the Deploy WordPress Script

To create and configure user for the FTP server:

Navigate to Runlogs > Run a Script

Configure the runlog:
- Server: Select the same server where you ran the setup
- Script: Choose “FTP Configuration Script”
- Variable Group: Select your predefined variables (or create new ones for this site)
Click Run Now to deploy

Once the script runs successfully, your FTP server user will be created and configured. You can test connectivity using FileZilla.

This show that the FTP server is working successfully.

Get Started with CloudRay

How to Automate WordPress Multi-Site Backups

Tue, 29 Apr 2025 00:00:00 GMT

This guide demonstrates how to implement an automated WordPress backup solution for enterprise-grade protection using CloudRay. You will learn how to create isolated backups for WordPress sites (files and database), implement retention policies to manage storage usage, and schedule automated backups using CloudRay’s Schedules feature.

IMPORTANT

Before implementing these backup solutions, ensure you have multiple WordPress sites deployed with isolated users and databases. If you haven’t set this up yet, follow our comprehensive guide on Deploy Multiple WordPress Sites on One Server.

Adding Servers to CloudRay
Create Backup Scripts
- Backup WordPress Sites Database Script
- Backup WordPress Sites Files Script
Create a Variable Group
How to Schedule Automated WordPress Backups for Databases
How to Schedule Automated WordPress Backups for Filesystem

Adding Servers to CloudRay

Before getting started with your automation, 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

NOTE

This guide uses Bash scripts, providing a high degree of customisation. You can adapt the scripts to fit your specific installation needs and environment. Additionally, if you’re using a different version or a different distribution, adjust the commands accordingly.

Create Backup Scripts

To fully protect your WordPress multi-site installation, you can implement two specialised backup solutions. The Backup WordPress Sites Database Script securely exports all database content with transaction consistency, while the Backup WordPress Sites Files Script preserves your complete file structure including themes, plugins, and uploads.

To automate Backups, you will need two bash scripts:

Backup WordPress Sites Database Script: This script creates compressed, transaction-safe exports of each WordPress database while verifying data integrity and maintaining proper user isolation
Backup WordPress Sites Files Script: This script archives all critical WordPress files while excluding temporary data, with built-in verification to ensure backup reliability

These WordPress backup scripts solve critical challenges for multi-site administrators by providing:

Scheduled WordPress backups that run without manual intervention
Secure WordPress backups with integrity verification
A complete WordPress backup solution covering both database and files

Backup WordPress Sites Database Script

To create your automated database backup script in CloudRay, follow these steps to create the script that will protect your WordPress site critical data:

Go to Scripts → New Script
Name it Backup WordPress Sites Database Script
Add the following script:

#!/bin/bash

# Exit on error
set -e

# Create backup directory if not exists
sudo mkdir -p "{{backup_dir}}" || { echo "Failed to create backup directory"; exit 1; }

{
    echo "=== Starting Database Backup at $(date) ==="
    echo "Host: $(hostname)"
    echo "MySQL Version: $(mysql --version)"

    # Verify MySQL connectivity
    if ! mysql -u "{{db_user1}}" -p"{{db_pass1}}" -e "SHOW DATABASES;" >/dev/null 2>&1; then
        echo "ERROR: Cannot connect to MySQL server"
        exit 1
    fi

    # Backup first WordPress database
    echo "Backing up database {{db1}} to {{backup_dir}}/{{db1}}_db_{{timestamp}}.sql.gz"
    if mysqldump --single-transaction --quick \
        -u "{{db_user1}}" -p"{{db_pass1}}" "{{db1}}" \
        | gzip > "{{backup_dir}}/{{db1}}_db_{{timestamp}}.sql.gz"; then

        if gzip -t "{{backup_dir}}/{{db1}}_db_{{timestamp}}.sql.gz"; then
            echo "SUCCESS: {{db1}} backup (Size: $(du -h "{{backup_dir}}/{{db1}}_db_{{timestamp}}.sql.gz" | cut -f1))"
            zgrep -q "wp_options" "{{backup_dir}}/{{db1}}_db_{{timestamp}}.sql.gz" || echo "WARNING: Missing WordPress tables in {{db1}} backup"
        else
            echo "ERROR: Backup verification failed for {{db1}}"
            sudo rm -f "{{backup_dir}}/{{db1}}_db_{{timestamp}}.sql.gz"
        fi
    else
        echo "ERROR: Database backup failed for {{db1}}"
    fi

    # Apply retention policy
    echo "Cleaning up backups older than {{retention_days}} days..."
    find "{{backup_dir}}" -name "*_db_*.sql.gz" -mtime +{{retention_days}} -delete

    echo "=== Database Backup Completed at $(date) ==="
    echo "Remaining backups:"
    ls -lh "{{backup_dir}}"/*_db_*.sql.gz 2>/dev/null || echo "No database backups found"
    echo "Disk usage: $(df -h {{backup_dir}})"
} | tee -a "{{db_log_file}}"

Here is a breakdown of what the Backup WordPress Sites Database Script does:

Creates transaction-consistent backups using mysqldump --single-transaction to avoid database locking during backups
Compresses database dumps with gzip to minimise storage usage while maintaining data integrity
Verifies backup completeness by checking for essential WordPress tables like wp_options
Implements automatic retention by deleting backups older than the specified number of days
Provides detailed logging with timestamps, success/failure status, and backup sizes
Validates MySQL connectivity before attempting backups to prevent partial failures
Maintains isolated backups for each WordPress site according to your multi-site architecture
Includes corruption checks using gzip -t to automatically detect and remove invalid backups

Backup WordPress Sites Files Script

Similarly, to create your automated WordPress files backup script in CloudRay, follow these steps to create the script:

Go to Scripts → New Script
Name it Backup WordPress Sites Files Script
Add the following script:

#!/bin/bash

# Exit on error
set -e

# Create backup directory if not exists
sudo mkdir -p "{{backup_dir}}" || { echo "Failed to create backup directory"; exit 1; }

{
    echo "=== Starting Backup at $(date) ==="

    for USER in {{user1}}; do
        WP_DIR="/home/$USER/public_html"

        # Verify user directory exists
        if [ ! -d "$WP_DIR" ]; then
            echo "ERROR: Directory $WP_DIR not found for user $USER"
            continue
        fi

        BACKUP_FILE="{{backup_dir}}/${USER}_files_{{timestamp}}.tar.gz"

        echo "Backing up $WP_DIR to $BACKUP_FILE"

        # Create backup with verbose output
        if sudo tar -czvf "$BACKUP_FILE" \
            --exclude='cache/*' \
            --exclude='.git/*' \
            -C / "home/$USER/public_html" 2>&1; then

            # Verify backup integrity
            if sudo gzip -t "$BACKUP_FILE"; then
                echo "SUCCESS: Backup created for $USER (Size: $(du -h "$BACKUP_FILE" | cut -f1))"
            else
                echo "ERROR: Backup verification failed for $USER"
                sudo rm -f "$BACKUP_FILE"
            fi
        else
            echo "ERROR: Backup failed for $USER"
        fi
    done

    echo "=== Backup completed at $(date) ==="
    echo "Disk usage: $(df -h {{backup_dir}})"
} | tee -a "{{log_file}}"

Here is a breakdown of what the Backup WordPress Sites Files Script does:

Creates compressed archives of each WordPress site’s public_html directory using tar+gzip for efficient storage
Maintains file permissions by running as sudo to properly backup all WordPress files
Excludes non-essential files like cache and git directories to reduce backup size
Verifies backup integrity with gzip -t to ensure archives are not corrupted
Provides detailed logging including timestamps, file sizes, and success/failure status
Handles multiple sites by iterating through all configured WordPress users
Checks directory existence before attempting backups to prevent errors
Tracks disk usage after completion to monitor storage consumption
Preserves directory structure using -C flag for proper restoration and outputs verbose progress during archive creation for monitoring

Create a Variable Group

These backup scripts builds on the same variables used in the guide Deploy Multiple WordPress Sites. However, you need to define values for the following placeholders {{backup_dir}}, {{timestamp}}, {{log_file}}, {{db_log_file}}, and {{retention_days}} used in the scrips.

Follow these steps to edit the variable group and include the new variables to ensure that these new values are automatically substituted when the script runs:

Navigate to Variable Groups: In your CloudRay project, go to “Scripts” in the top menu and click on “Variable Groups”.
Edit the Variable Group: Click on variable group you created earlier for the WordPress sites and edit it
Add the following variables:

backup_dir: The central directory of all backups
timestamp: time format for naming the backups
log_file: Filesystem backup logs
db_log_file: Database backup logs
retention_days: Auto-delete backups older than X days

Since the variables are setup, proceed to creating backups schedules with CloudRay.

How to Schedule Automated WordPress Backups for Databases

CloudRay offers Schedules, allowing you to execute scripts automatically at specific intervals or times. This feature is useful for tasks such as automating database backups.

For example, if you want to back up your WordPress sites database on the first day of every month at 12:00 AM, you can configure a CloudRay schedule to handle this automatically.

Here are the steps to achieve this:

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 WordPress sites database is regularly backed up without manual intervention.

How to Schedule Automated WordPress Backups for Filesystem

For comprehensive WordPress protection, you can implementing a weekly filesystem backup schedule alongside your database backups.

For example, if you want to backup your WordPress sites filesystem weekly every sunday at 2:00AM, you can configure a CloudRay schedule. Similarly, here is how to achieve this:

Click “Add Schedule”: Start creating a new schedule.

Submit Schedule: Click “Submit” to activate your new schedule.

With this schedule in place, CloudRay will automatically perform weekly backups of your WordPress files every Sunday at 2:00 AM, ensuring your site content remains protected without manual intervention.

TIP

These scripts are designed for easy reuse across multiple WordPress sites. Simply edit the variable group to include additional database credentials (db2, db_user2, etc.) or users (user2, user3) as needed. CloudRay will automatically apply the updated variables when the scheduled backups execute, allowing the same scripts to manage backups for any number of WordPress installations.

Get Started with CloudRay

Deploy Multiple WordPress Sites on One Server

Mon, 28 Apr 2025 00:00:00 GMT

This guide outlines a method for deploying isolated WordPress instances with enhanced security measures, leveraging automated provisioning through bash scripts executed via CloudRay.

The deployment model addresses three core requirements:

User-level process isolation where each WordPress instance runs under its own Linux system account
Database security via separate MySQL accounts
Automated SSL certificate provisioning

This approach prevents cross-site contamination from common WordPress threats including malware infections via vulnerable plugins, credential stuffing attacks, and file inclusion exploits.

Adding Servers to CloudRay
Create the Automation Script
- Server Environment Setup
- Deploy Wordpress
Create a Variable Group
Running the Script with CloudRay
- Running Server Environment Setup Script
- Running the Deploy WordPress Script
Restart WordPress Server (Optional)
Managing WordPress Files After Deployment

Adding Servers to CloudRay

Before getting started with your automation, 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

NOTE

Create the Automation Script

To streamline the deployment and management processes, you’ll need three Bash scripts:

Server Environment Setup: Installs dependencies, creates users, and configures the server environment
Deploy Wordpress: Downloads WordPress, configures databases, and sets up Caddy virtual hosts

Server Environment Setup

This script prepares your server by installing all required dependencies and configuring the base environment for isolated WordPress installations. To create the Server Environment Setup script, you need to follow these steps:

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

#!/bin/bash

# Exit on error
set -e

# Update and upgrade
sudo apt update -y

# Install PHP and required modules
sudo apt install -y php php-common php-mysql php-xml php-xmlrpc php-curl php-gd php-imagick php-cli php-dev php-imap php-mbstring php-soap php-zip php-intl php-cgi php8.3-fpm unzip

# Install Caddy web server
sudo apt update
sudo apt install -y caddy

Below is a breakdown of what the Server Environment Setup does:

Updates all system packages to their latest versions
Installs PHP 8.3 with FPM pools optimised for WordPress
Deploys Caddy with automatic HTTPS configuration

This script assumes MySQL is already installed. For configuring a remote MySQL server instead, see our MySQL Server Guide.

Deploy Wordpress

Once your server environment is prepared, this script handles the actual WordPress deployment process for each isolated user account. It takes care of downloading WordPress, configuring database connections, setting appropriate permissions, and configuring Caddy to serve each site securely.

To create the Deploy WordPress Script, follow these steps:

Go to Scripts > New Script
Name: Deploy Wordpress
Add code:

#!/bin/bash

# Exit on error
set -e

# Add users with passwords (non-interactive)
echo -e "{{pass}}\n{{pass}}" | sudo adduser --gecos "" {{user}} --disabled-password
echo "{{user}}:{{pass}}" | sudo chpasswd

# Create web directories
sudo mkdir -p /home/{{user}}/public_html

# Install MySQL and create databases & users
sudo mysql -u root <<EOF
CREATE DATABASE {{db}};
CREATE USER '{{db_user}}'@'localhost' IDENTIFIED BY '{{db_pass}}';
GRANT ALL PRIVILEGES ON {{db}}.* TO '{{db_user}}'@'localhost';
FLUSH PRIVILEGES;
EOF

# Configure PHP-FPM pool
sudo tee /etc/php/8.3/fpm/pool.d/{{user}}.conf > /dev/null <<EOF
[{{user}}]
user = {{user}}
group = www-data
listen = /run/php/{{user}}.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
chdir = /
security.limit_extensions = .php
php_admin_value[error_log] = /var/log/php8.3-fpm/{{user}}-error.log
php_admin_flag[log_errors] = on
EOF

# Restart PHP-FPM service
sudo systemctl restart php8.3-fpm

# Set ownership and permissions
sudo chown -R {{user}}:{{user}} /home/{{user}}
sudo chmod 755 /home/{{user}}/public_html

# Download and configure WordPress for USER
sudo -u {{user}} bash <<EOF
cd ~/public_html
wget https://wordpress.org/latest.tar.gz
tar xzf latest.tar.gz --strip-components=1
rm latest.tar.gz
cp wp-config-sample.php wp-config.php
sed -i "s/database_name_here/{{db}}/" wp-config.php
sed -i "s/username_here/{{user}}/" wp-config.php
sed -i "s/password_here/{{db_pass}}/" wp-config.php
EOF

# Set final permissions
sudo chown -R {{user}}:www-data /home/{{user}}/public_html
sudo find /home/{{user}}/public_html -type d -exec chmod 750 {} \;
sudo find /home/{{user}}/public_html -type f -exec chmod 640 {} \;
sudo chmod 600 /home/{{user}}/public_html/wp-config.php
sudo chmod 710 /home/{{user}}
sudo chown -R {{user}}:www-data /home/{{user}}
sudo chmod 750 /home/{{user}}
sudo chmod 755 /home/{{user}}/public_html
sudo -u www-data ls -la /home/{{user}}/public_html

# Setup Caddy configuration
sudo tee /etc/caddy/Caddyfile > /dev/null <<EOF
{{domain}} {
    root * /home/{{user}}/public_html
    php_fastcgi unix//run/php/{{user}}.sock
    file_server
    encode gzip
}
EOF

# Reload Caddy and check services
sudo systemctl reload caddy
sudo systemctl status php8.3-fpm caddy

This is what the Deploy Wordpress does:

Creates Linux user (For example, {{user1}}) with dedicated directory
Sets strict file ownership (user:www-data) and socket permissions
Sets ownership and permissions for the user web directory
Downloads and extracts WordPress for user under its isolated directory
Configures unique database credentials in wp-config.php for each instance
Applies secure file and directory permissions to protect sensitive files and limit access
Generates a Caddyfile with virtual host configurations for domains, mapping each to its respective PHP-FPM pool
Reloads Caddy and verifies service status to apply the changes

With this script, your WordPress sites will be fully deployed, isolated by user accounts, securely served over HTTPS via Caddy.

Create a Variable Group

Before running the scripts, you need to define values for the placeholders {{user}}, {{pass}}, {{db}}, {{db_user}}, {{db_pass}}, 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:

user: The Linux system users for the Wordpress site
pass: The password for the Linux users
db: The name of the MySQL database for the Wordpress site
db_user: The MySQL username
db_pass: The password of the database users
domain: The domain name associated with the Wordpress site

Running the Script with CloudRay

You can run the scripts individually or execute them all at once using CloudRay’s Script Playlists. The deployment process involves two distinct phases:

Server Environment Setup: Run once per server to install dependencies
WordPress Deployment: Run separately for each site you want to deploy

Running Server Environment Setup Script

Follow these steps:

Navigate to Runlogs in your CloudRay project
Click New Run a Script

Configure the runlog:
- Server: Select your target server
- Script: Choose “Server Environment Setup”
- Variable Group: Select the variable group you created earlier
Run the script: Click on “Run” to execute the script on your server

CloudRay will connect to your server, run the Server Environment Setup script, and show you the live output as the script executes. This one-time setup installs all required system packages and services. You only need to run this script once when setting up a new server.

Running the Deploy WordPress Script

For each WordPress site you want to deploy:

Navigate to Runlogs > Run a Script

Configure the runlog:
- Server: Select the same server where you ran the setup
- Script: Choose “Deploy WordPress”
- Variable Group: Select your predefined variables (or create new ones for this site)
Click Run Now to deploy

You can now visit one of the Wordpress sites using your domains (For Example, https://site1.com, https://site2.com, etc).

Your Wordpress sites are now deployed and managed with CloudRay.

If you wish to deploy additional WordPress sites on your server using CloudRay, the process is straightforward. Simply update the variables in your Variable Group such as user, pass, db, db_user, db_pass, and domain to reflect the new site’s details. Once these variables are set, rerun the existing Deploy WordPress script through CloudRay. This approach allows you to provision new, isolated WordPress instances efficiently, without modifying the underlying scripts.

TIP

You can create multiple variable groups in CloudRay to store configurations for different WordPress sites, making it easy to redeploy or manage them individually.

Restart WordPress Server (Optional)

For maintenance or troubleshooting, use this script to safely restart all WordPress services while minimising downtime. It preserves active connections and verifies each component.

Go to Scripts > New Script in CloudRay
Name: “Restart WordPress Services”

Paste the following code:

#!/bin/bash

# CloudRay: WordPress Service Restarter
# Safely reloads PHP-FPM, Caddy, and verifies MySQL

echo "🔄 Starting WordPress service restart sequence..."

# Graceful PHP-FPM reload (maintains active connections)
sudo systemctl reload php8.3-fpm && \
echo "✅ PHP-FPM reloaded (zero-downtime)"

# Hard Caddy restart (ensures config reload)
sudo systemctl restart caddy && \
echo "✅ Caddy restarted with fresh config"

# MySQL status check (no restart)
mysql_status=$(sudo systemctl is-active mysql)
[ "$mysql_status" = "active" ] && \
echo "✅ MySQL verified (running)" || \
echo "⚠️ MySQL status: $mysql_status"

# Post-restart verification
echo -e "\n🔍 Service Status Summary:"
sudo systemctl status php8.3-fpm caddy mysql --no-pager

# WordPress connectivity test
echo -e "\n🌐 Testing WordPress at {{domain}}..."
curl -Is https://{{domain}} | grep -E "HTTP|Location" || \
echo "Failed to connect to WordPress"

echo -e "\n🟢 Restart completed at $(date +'%Y-%m-%d %H:%M:%S')"

Run this script with the same variable group as your WordPress site to automatically test the correct domain.

Managing WordPress Files After Deployment

Once your WordPress sites are deployed, you may need to manage files directly. For secure file transfers, we recommend setting up an FTP server with user isolation that matches your WordPress account structure. Our guide on Automating FTP Server Installation with CloudRay shows how to configure vsftpd with the same user accounts created for WordPress, enabling secure file management through clients like FileZilla while maintaining your security isolation.

The multi-site deployment approach used here provides several advantages:

Resource Efficiency: Hosting multiple isolated WordPress instances on a single server optimises hardware utilisation
Simplified Management: Centralised administration through CloudRay while maintaining site independence
Cost Effective: Eliminates the need for separate servers for each WordPress installation
Consistent Security: Uniform security policies with individualised access controls

For production environments, consider implementing our Automated WordPress Backup Solution to protect all sites simultaneously while maintaining their isolated structures.

Get Started with CloudRay

Automate the Installation of Redis Server

Tue, 22 Apr 2025 00:00:00 GMT

Redis deployments require proper configuration of network binding, memory management, and authentication to prevent unauthorised access. This guide demonstrates how to automate Redis Server installation with CloudRay. This automation with CloudRay would implement secure password authentication, proper daemon configuration, network binding restrictions, and service lifecycle management.

Adding Servers to CloudRay
Create the Automation Script
- Redis Installation Script
- Redis Configuration Script
Create a Variable Group
Running the Scripts to Install Redis with CloudRay

Adding Servers to CloudRay

Before beginning Redis deployment, ensure your target servers are connected to CloudRay. Follow the servers docs to add and manage servers if not already configure

NOTE

These scripts target Ubuntu/Debian systems. For RHEL-based distributions, replace apt commands with appropriate yum or dnf equivalents. The Redis configuration file path may differ on non-Debian systems.

Create the Automation Script

Two Bash scripts are required for complete Redis deployment:

Redis Installation Script:: This script handles package installation and base configuration
Redis Configuration Script: This script implement security settings and authentication

Let’s begin with the Redis installation script.

Redis Installation Script

This script performs the initial Redis Server deployment with production-ready defaults. Follow these steps to create the script:

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

#!/bin/bash

# Exit on any error
set -e

# Update package list
sudo apt update

# Install Redis server
sudo apt install redis-server -y

# Display installed Redis version
redis-server --version

# Modify redis.conf:
# - Uncomment 'bind 127.0.0.1 -::1'
# - Ensure daemonize is 'yes'
sudo sed -i 's/^# *bind 127.0.0.1 ::1/bind 127.0.0.1 ::1/' /etc/redis/redis.conf
sudo sed -i 's/^# *daemonize no/daemonize yes/' /etc/redis/redis.conf

# Enable Redis service to start on boot
sudo systemctl enable redis-server.service

# Start Redis service
sudo systemctl start redis

# Check Redis service status
sudo systemctl status redis --no-pager

Here is a breakdown of what each command in the Redis Installation Script does:

Installs Redis from system packages
Configures loopback interface binding
Enables daemon mode for service management
Verifies successful service start

Redis Configuration Script

This script implements security controls and tests basic functionality.

Go to Scripts > New Script
Name: Redis Configuration Script
Add code:

#!/bin/bash

# Exit on any error
set -e

# Modify redis.conf:
# - Uncomment and set requirepass to the strong password
sudo sed -i "s/^# *requirepass .*/requirepass {{redis_password}}/" /etc/redis/redis.conf

# Restart Redis service to apply changes
sudo systemctl restart redis

# Connect to Redis CLI and test authentication & set/get commands
redis-cli <<EOF
auth {{redis_password}}
select 1
set testkey "Hello from CloudRay!"
get testkey
EOF

echo "✅ Redis authentication and test command successful."

This is what the Secure Cockpit Script does:

Enables password authentication
Restarts service to apply security settings
Validates configuration with test operations

Create a Variable Group

The configuration script requires a password variable. Create a variable group to store this securely. 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 Group under Scripts
Create a new group named Redis Deployment Variables
Add the following variables:

redis_password: The password for Redis authentication

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

Running the Scripts to Install Redis with CloudRay

The Redis deployment consists of two dependent scripts that should execute sequentially. CloudRay’s Script Playlists provide an efficient way to orchestrate this workflow.

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 Redis Server Installation”)
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 Redis will be installed
Script Playlist: Choose the playlist you created (For example “Automate Redis Server Installation”)
Variable Group: Select the variable group you set up earlier

Execute the Script: Click on Run Now to start the execution

After successful script execution to install Redis Server. Validate the Redis installation by clicking the Runlog of the Configure Redis Script

As seen in the ouput, Redis is successfully working correctly.

IMPORTANT

For production environments, we recommend running the installation playlist on multi nodes, configuring Redis Sentinel for higher availability, setting up monitoring.

For other database deployments using CloudRay check out our guides on:

Get Started with CloudRay

Automating Web App Deployment with Terraform, GitHub, and CloudRay

Mon, 07 Apr 2025 00:00:00 GMT

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

Automate the Installation of Cockpit

Sun, 06 Apr 2025 00:00:00 GMT

Automating Cockpit deployment on Rocky Linux 9 ensures consistent, secure server management with minimal manual intervention. CloudRay simplifies this process by handling dependencies, configurations, and security hardening through Bash scripted workflows.

This guide walks through automating Cockpit setup with SSL encryption and firewall rules using CloudRay.

Adding Servers to CloudRay
Create the Automation Script
- Install Cockpit Script
- Secure Cockpit Script
Create a Variable Group
Running the Scripts to Install Cockpit with CloudRay
Troubleshooting
Related Guide

Adding Servers to CloudRay

Before getting started with your automation, 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

NOTE

Create the Automation Script

To automate the installation of Cockpit, you will need two Bash scripts:

Install Cockpit Script: This script installs and setup cockpit
Secure Cockpit Script: This script configures firewall rules, enables HTTPS encryption with Let’s Encrypt certificates, and secures remote access to the Cockpit web interface

Let’s begin with the installation of Cockpit.

Install Cockpit Script

To create the Install Cockpit Script, you need to follow these steps:

Go to Scripts in your CloudRay project
Click New Script
Name: Install Cockpit 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 Cockpit
sudo dnf install cockpit -y

# Enable and start Cockpit service
sudo systemctl enable cockpit.socket
sudo systemctl start cockpit

# Check Cockpit status
sudo systemctl status cockpit

# Create an admin user for Cockpit
sudo adduser {{admin_user}}
echo "{{admin_pass}}" | sudo passwd {{admin_user}} --stdin
sudo usermod -aG wheel {{admin_user}}

echo "Cockpit installation and basic setup completed!"

Here is a breakdown of what each command in the Install Cockpit Script does:

Updates all installed packages to the latest version
Installs Cockpit and dependencies
Creates a privileged user with variables for credentials

Secure Cockpit Script

Next, you need secure the Cockpit installed on your server. To do so, follow similar steps as the above:

Go to Scripts > New Script
Name: Secure Cockpit Script
Add code:

#!/bin/bash

# Exit on error
set -e

# Install Firewalld
sudo dnf install firewalld -y
sudo systemctl start firewalld
sudo systemctl enable firewalld

# Configure firewall rules
sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --permanent --add-port=9090/tcp
sudo firewall-cmd --reload

# Install EPEL and Certbot
sudo dnf install epel-release -y
sudo dnf install certbot -y

# Obtain SSL certificate
sudo certbot certonly --standalone -d {{domain}} -m {{email}} --agree-tos --no-eff-email --non-interactive

# Test certificate renewal
sudo certbot renew --dry-run

# Link SSL certificates to Cockpit
sudo ln -sf /etc/letsencrypt/live/{{domain}}/fullchain.pem {{cockpit_cert_dir}}/certificate.cert
sudo ln -sf /etc/letsencrypt/live/{{domain}}/privkey.pem {{cockpit_cert_dir}}/certificate.key

# Restart Cockpit to apply SSL
sudo systemctl restart cockpit

echo "Cockpit security configuration completed!"

This is what the Secure Cockpit Script does:

Install and configures firewall rules
Sets up Let’s Encrypt SSL certificates
Enforces HTTPS for Cockpit’s web interface

Create a Variable Group

Now, before running the scripts, you need to define values for the placeholders {{admin_user}}, {{admin_pass}}, {{domain}}, {{email}}, and {{cockpit_cert_dir}} 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:

admin_user: The username for the Cockpit administrator account
admin_pass: The password for the Cockpit administrator account
domain: The registered domain name for SSL certificate configuration
email: The email address associated with the SSL certificate (used for renewal alerts)
cockpit_cert_dir: The directory path where Cockpit stores its SSL certificates

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

Running the Scripts to Install Cockpit with CloudRay

Now that everything is setup, you can use CloudRay to automate the installation of Cockpit.

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 Cockpit Deployment and Management”)
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 Cockpit will be installed
Script Playlist: Choose the playlist you created (For example “Automate Cockpit Deployment and Management”)
Variable Group: Select the variable group you set up earlier

Execute the Script: Click on Run Now to start the execution

Once the script runs successfully, your Cockpit will be fully deployed. You can now visit your Cockpit using your domain on port 9090 (https://cockpit.mydomain.com:9090).

Your Cockpit is now deployed and managed with CloudRay.

Troubleshooting

If you encounter issues during Cockpit installation or setup, consider the following:

Cockpit Web Interface Not Loading:: Check if the Cockpit service is running with sudo systemctl status cockpit.socket and restart it using sudo systemctl restart cockpit.socket
SSL Certificate Errors: Verify certificate validity with sudo certbot certificates and renew if needed using sudo certbot renew
Firewall Blocking Access: Ensure port 9090 is open by running sudo firewall-cmd --list-ports | grep 9090 and add it if missing: sudo firewall-cmd --add-port=9090/tcp --permanent && sudo firewall-cmd --reload

If the issue persists, consult the official Cockpit documentation for further assistance.

Get Started with CloudRay

Related Guide

Automate the Installation of MongoDB

Sat, 05 Apr 2025 00:00:00 GMT

Automating MongoDB deployment on remote servers can significantly streamline your database management process. CloudRay provides automation capabilities that eliminate manual configuration steps while ensuring consistency across environments.

In this guide, you will learn how to automate MongoDB installations and manage your entire deployment through CloudRay’s centralised platform. Finally, you will learn how to schedule automated backups for data protection.

By the end of this article, you will have a fully automated MongoDB deployment with built-in security and maintenance workflows.

Adding Servers to CloudRay
Assumptions
Create the Automation Script
- MongoDB Installation Script
- User Configuration Script
Create a Variable Group
Running the Script with CloudRay
Scheduling MongoDB Database Backup with CloudRay’s Schedules (Optional)
Related Guides

Adding Servers to CloudRay

Before getting started with your automation, 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

NOTE

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

Assumptions

This guide assumes you’re using Ubuntu 24.04 LTS 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

We’ll use three specialized scripts to automate the MongoDB deployment:

MongoDB Installation Script: This script will handle MongoDB package installation and basic security configuration
User Configuration Script: This script will creates administrative and application users with proper roles
Backup Script: This script will configures automated database backups with retention policies

Let’s begin with the MongoDB MongoDB Installation Script.

MongoDB Installation Script

To create the MongoDB Installation Script, you need to follow these steps:

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

#!/bin/bash

# Exit immediately on errors
set -e

# Install MongoDB
curl -fsSL https://www.mongodb.org/static/pgp/server-{{mongo_version}}.asc | sudo gpg -o /usr/share/keyrings/mongodb-server-{{mongo_version}}.gpg --dearmor

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-{{mongo_version}}.gpg ] https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/{{mongo_version}} multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-{{mongo_version}}.list

sudo apt update
sudo apt install -y mongodb-org

# Start and enable MongoDB
sudo systemctl enable mongod
sudo systemctl start mongod

# Verify installation
mongod --version
sudo systemctl status mongod

# Enable authentication in MongoDB configuration
sudo sed -i '/#security:/a security:\n  authorization: enabled' /etc/mongod.conf

# Restart MongoDB to apply changes
sudo systemctl restart mongod

echo "MongoDB installation and configuration completed successfully!"

Here is a breakdown of what each command in the MongoDB Installation Script does:

Adds MongoDB’s official repository with GPG verification
Installs the latest MongoDB packages
Enables and starts the MongoDB service
Configures mandatory authentication
Verifies successful installation

User Configuration Script

After MongoDB installation, we need to properly configure database users with least-privilege access. This script creates:

An administrative user with global management privileges
An application user with restricted database access

Similarly, follow these steps to create the user configuration script:

Go to Scripts > New Script
Name: User Configuration Script
Add code:

#!/bin/bash

set -e

# Create admin user
mongosh <<EOF
use admin

db.createUser({
  user: "{{admin_user}}",
  pwd: "{{admin_pass}}",
  roles: [
    { role: "userAdminAnyDatabase", db: "admin" },
    { role: "readWriteAnyDatabase", db: "admin" },
    { role: "dbAdminAnyDatabase", db: "admin" }
  ]
})

exit
EOF

# Authenticate with admin user and create application user
mongosh -u "{{admin_user}}" -p "{{admin_pass}}" --authenticationDatabase admin <<EOF
use {{db_name}}

db.createUser({
  user: "{{db_user}}",
  pwd: "{{db_pass}}",
  roles: [ { role: "readWrite", db: "{{db_name}}" } ]
})

exit
EOF

# Insert test data
mongosh -u "{{db_user}}" -p "{{db_pass}}" --authenticationDatabase "{{db_name}}" <<EOF
use {{db_name}}

db.messages.insertOne({ message: "Greetings from CloudRay" })

exit
EOF

echo "MongoDB users have been successfully created!"

This is what the User Configuration Script does:

Creates an administrative user with: user management privileges, cluster management rights, and global read/write access
Create an application-specific user with: restriction to single database and only read/write privileges (no admin rights)
Insert test data to verify functionality

Create a Variable Group

Now, before running the scripts, you need to define values for the placeholders {{mongo_version}}, {{admin_user}}, {{admin_pass}}, {{db_user}}, {{db_pass}}, {{db_name}}, and {{backup_dir}} 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:

mongo_version: This is the MongoDB version to be installed
admin_user: This is the administrative user
admin_pass: This is the password of the administrative user
db_user: This is the application user
db_pass: The application password
db_name: The application database name
backup_dir: The backup directory of MongoDB

Since the variables are setup, proceed with running the scripts with CloudRay

Running the Script with CloudRay

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 “MongoDB Setup Automation and Management”)
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 you need MongoDB to be installed
Script Playlist: Choose the playlist you created (For example “MongoDB Setup Automation and Management”)
Variable Group: Select the variable group you set up earlier

Execute the Script: Click on Run Now to start the execution

Your MongoDB is now seamlessly setup and managed with CloudRay. That’s it! Happy deploying!

Scheduling MongoDB Database Backup with CloudRay’s Schedules (Optional)

CloudRay also offers Schedules, allowing you to execute scripts automatically at specific intervals or times. This feature is useful for tasks such as automating database backups.

To automate MongoDB database backups with CloudRay, you first need to create a backup script that the scheduler will execute.

You can follow similar steps as the previous ones to create the backup script:

Go to Scripts > New Script
Name: Backup MongoDB Database
Add code:

#!/bin/bash

# Exit on error
set -e

# Ensure backup directory exists
mkdir -p "{{backup_dir}}"

# Perform compressed backup
mongodump --authenticationDatabase "{{db_name}}" \
          -u "{{db_user}}" \
          -p "{{db_pass}}" \
          --db "{{db_name}}" \
          --gzip \
          --archive="{{backup_dir}}/{{db_name}}_$(date +%F_%H-%M-%S).gz"

# Confirm backup success
if [ $? -eq 0 ]; then
    echo "Backup successful: {{backup_dir}}/{{db_name}}_$(date +%F_%H-%M-%S).gz"
    # Optional: Delete backups older than 30 days
    find "{{backup_dir}}" -name "{db_name}_*.gz" -type f -mtime +30 -delete
else
    echo "Backup failed!"
    exit 1
fi

This is what the Backup MongoDB Database does:

Compressed backups with timestamps
Automatic retention policy (30 days)
Checks if the backup was successful: If successful, it prints the backup path; otherwise, it reports failure and exits with an error code.

For example, if you want to back up your database on the first day of every month at 12:00 AM, you can configure a CloudRay schedule to handle this automatically.

Here are the steps to achieve this:

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 database is regularly backed up without manual intervention.

Get Started with CloudRay

Related Guides

Deploy a Laravel Application with Caddy

Wed, 02 Apr 2025 00:00:00 GMT

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.

Adding Servers to CloudRay
Assumptions
Create the Automation Script
Create a Variable Group
Running the Script with CloudRay
Troubleshooting
Related Guides

Adding Servers to CloudRay

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.

NOTE

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

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.

Get Started with CloudRay

Related Guides

Deploy Your Next.js Application

Mon, 31 Mar 2025 00:00:00 GMT

CloudRay offers a streamlined approach to automating and managing deployments across various environments. In this guide, we will walk through the process of deploying a Next.js application using CloudRay automation Bash scripts.

By the end of this article, you will have a fully functional Next.js application running behind a Caddy reverse proxy with process management handled by PM2.

Adding Servers to CloudRay
Assumptions
Create the Automation Script
- Setup Nextjs Script
- Deploy Nextjs Script
Create a Variable Group
Running the Script with CloudRay
- Run the Setup Nextjs Script
- Run the Deploy Nextjs Script
Troubleshooting

Adding Servers to CloudRay

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.

NOTE

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

Assumptions

This guide assumes you’re using Ubuntu 24.04 LTS 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 automate the setup and deployment, you’ll need two Bash scripts:

Setup Nextjs Script: This script will install the application dependencies and build the Next.js application
Deploy Nextjs Script: This script will automate the deployment processes by installing and configuring Caddy as a reverse proxy and secure the domain

Let’s begin with the Setup Nextjs Script

Setup Nextjs Script

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

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

#!/bin/bash

# Exit on error
set -e

# Install Node.js and npm
echo "Installing Node.js and npm..."
sudo apt update && sudo apt install -y nodejs npm

# Install PM2 globally
echo "Installing PM2..."
sudo npm install -g pm2

# Clone the Next.js application
echo "Cloning Next.js repository..."
sudo mkdir -p /var/www
cd /var/www
sudo git clone https://{{github_access_token}}@github.com/{{github_user}}/{{repo_name}}.git

# Install dependencies and build the application
cd {{repo_name}}
echo "Installing dependencies and building the application..."
npm install
npm run build

echo "Setup completed successfully!"

Here is what the Setup Nextjs Script does:

Installs Node.js, npm, and PM2
Clones the Next.js repository from GitHub
Installs dependencies and builds the Next.js application

Deploy Nextjs Script

Next, to automate the deployment process, create the Deploy Nextjs Script by following these steps:

Go to Scripts > New Script
Name: Deploy Nextjs Script
Add code:

#!/bin/bash

# Exit on error
set -e

# Install dependencies and Caddy
echo "Installing Caddy and dependencies..."
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update && sudo apt install -y caddy

# Configure Caddy reverse proxy
echo "Configuring Caddy reverse proxy..."
sudo bash -c "cat > /etc/caddy/Caddyfile" <<EOF
{{domain}} {
    reverse_proxy localhost:3000
}
EOF

# Restart Caddy service
echo "Restarting Caddy..."
sudo systemctl restart caddy

# Navigate to the repository directory
cd /var/www/{{repo_name}}

# Fetch the latest changes from the remote repository
echo "Fetching latest changes from GitHub..."
git fetch --all

# Reset the local repository to match the remote main branch
echo "Resetting to the latest version of the main branch..."
git reset --hard origin/main

# Install dependencies and build the application
echo "Installing dependencies and building the application..."
npm install
npm run build

# Start the Next.js application using PM2
echo "Starting Next.js application..."
pm2 start npm --name "nextjs" -- start

# Configure PM2 to restart on boot
pm2 startup
pm2 save

echo "Deployment completed successfully!"

This is what the Deploy Nextjs Script does:

Installs Caddy and sets up a reverse proxy to the Next.js application
Fetches the latest changes from all branches in the remote repository and resets the local repository to match the latest commit on the main branch of the remote repository
Starts the Next.js application using PM2
Ensures the Next.js process restarts automatically on reboot

Create a Variable Group

Now, before running the scripts, you need to define values for the placeholders {{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:

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: Your application’s domain name, e.g., myapp.example.com

Since the variables is setup, proceed with running the scripts with CloudRay

Running the Script with CloudRay

You can choose to run the scripts individually or execute them all at once using CloudRay’s Script Playlists. If you prefer to run them individually, follow these steps:

Run the Setup Nextjs Script

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

To run the Setup Nextjs Script, 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 “Setup Nextjs Script”
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 Setup Nextjs Script, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Run the Deploy Nextjs Script

After successfully running the Setup Nextjs Script, the next step is to execute the Deployment Script using CloudRay’s Runlogs. This script will configure and deploy your application on the server.

To run the Deployment Script, 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: Provide the necessary details:

Server: Select the same server used earlier.
Script: Choose the “Deploy Nextjs Script”.
Variable Group: Select the variable group you created earlier.

Execute the Script: Click on Run Now to deploy your application.

Your Next.js application is now securely deployed and managed with CloudRay. That’s it! Happy deploying!

Troubleshooting

If you encounter issues during deployment, consider the following:

Ensure your domain is properly registered and set the A record to point to your server’s IP address
Verify that all necessary environment variables are correctly set on your Cloudray variable Group
Check that your firewall allows traffic on the required ports (e.g., 80, 443)

Get Started with CloudRay

How to Deploy SonarQube on Ubuntu

Sun, 30 Mar 2025 00:00:00 GMT

CloudRay simplifies cloud infrastructure automation by allowing users to execute Bash scripts on remote servers.

In this guide, you will learn how to automate the deployment of SonarQube on an Ubuntu server using CloudRay. SonarQube is an open-source platform for continuous inspection of code quality, providing static code analysis and detecting bugs, vulnerabilities, and code smells.

By the end of this guide, SonarQube will be running on your Ubuntu server, fully automated through CloudRay.

Adding Servers to CloudRay
Assumptions
Create the Automation Script
Create a Variable Group
Running the Script with CloudRay
Troubleshooting
Related Guides

Adding Servers to CloudRay

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

NOTE

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

Assumptions

This guide assumes you’re using Ubuntu 24.04 LTS 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 setup and management processes, you’ll need four Bash scripts:

Install and Configure PostgreSQL: This script installs PostgreSQL, creates a SonarQube database, and sets up a user with appropriate privileges
Install Java: This script installs Java 17, which is required to run SonarQube
Install and Configure SonarQube: This script downloads, extracts, and configures SonarQube to work with PostgreSQL
Configure System: This script adjusts system settings for performance optimization and sets up SonarQube as a systemd service

Let’s begin with the installation and configuration of PostgreSQL.

Install and Configure PostgreSQL Script

o create the Install and Configure PostgreSQL script, follow these steps:

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

#!/bin/bash

# Exit on any error
set -e

echo "Updating package lists..."
sudo apt update

echo "Adding PostgreSQL repository..."
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

echo "Adding PostgreSQL repository key..."
wget -qO- https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo tee /etc/apt/trusted.gpg.d/pgdg.asc &>/dev/null

echo "Updating package lists..."
sudo apt update

echo "Installing PostgreSQL..."
sudo apt-get -y install postgresql postgresql-contrib

echo "Enabling and starting PostgreSQL..."
sudo systemctl enable postgresql
sudo systemctl start postgresql

echo "Setting password for the 'postgres' user..."
echo "{{db_postgres_pass}}" | sudo passwd --stdin postgres

echo "Switching to PostgreSQL user to configure database..."
sudo -u postgres bash <<EOF
createuser {{db_user}}
psql -c "ALTER USER {{db_user}} WITH ENCRYPTED PASSWORD '{{db_pass}}';"
psql -c "CREATE DATABASE {{db_name}} OWNER {{db_user}};"
psql -c "GRANT ALL PRIVILEGES ON DATABASE {{db_name}} TO {{db_user}};"
EOF

echo "PostgreSQL installation and database setup completed!"

Here is a breakdown of what each command in the Install and Configure PostgreSQL does:

Updates the package lists to get the latest version of available packages
Adds the official PostgreSQL repository to the system
Downloads and adds the PostgreSQL repository’s GPG key for verifying package authenticity
Updates the package lists again to include the newly added PostgreSQL repository
Installs PostgreSQL and additional utilities for managing the database
Enables PostgreSQL to start automatically on system boot and starts the PostgreSQL service
Switches to the PostgreSQL user (postgres) and performs the following: creates a new database user with a password, creates a database and assigns its owner, and grants full access to the user on the database

Install Java

After the installation and configuration of PostgreSQL, you need to install Java.

Similarly, follow these steps to install Java:

Go to Scripts > New Script
Name: Install Java
Add code:

#!/bin/bash

# Exit on any error
set -e

echo "Downloading Java 17 repository key..."
wget -O - https://packages.adoptium.net/artifactory/api/gpg/key/public | tee /etc/apt/keyrings/adoptium.asc

echo "Adding Adoptium repository for Java 17..."
echo "deb [signed-by=/etc/apt/keyrings/adoptium.asc] https://packages.adoptium.net/artifactory/deb $(awk -F= '/^VERSION_CODENAME/{print$2}' /etc/os-release) main" | tee /etc/apt/sources.list.d/adoptium.list

echo "Updating package lists..."
apt update

echo "Installing Java 17..."
apt install temurin-17-jdk -y

echo "Setting Java 17 as the default..."
sudo update-alternatives --set java /usr/lib/jvm/temurin-17-jdk-amd64/bin/java

echo "Verifying Java installation..."
/usr/bin/java --version

echo "Java 17 installation completed!"

This is what the Install Java does:

Downloads and saves the GPG key for the Adoptium repository (Java 17 provider) and adds the Adoptium repository to the system
Updates the package lists to recognize the newly added Adoptium repository
Installs Java 17 from the Adoptium repository and sets Java 17 as the default version for the system

Install and Configure SonarQube Script

Moving forward, you need to create the install and configure SonarQube script.

You need to follow similar steps:

Go to Scripts in your CloudRay project
Click New Script
Name: Install and Configure SonarQube
Copy this code:

#!/bin/bash

# Exit on any error
set -e

echo "Installing required utilities..."
sudo apt-get install zip -y

echo "Downloading SonarQube..."
sudo wget https://binaries.sonarsource.com/Distribution/sonarqube/sonarqube-9.9.0.65466.zip

echo "Extracting SonarQube archive..."
sudo unzip sonarqube-9.9.0.65466.zip -d /opt
sudo mv /opt/sonarqube-9.9.0.65466 /opt/sonarqube

echo "Creating SonarQube user..."
sudo groupadd {{sonar_user}}
sudo useradd -c "User to run SonarQube" -d /opt/sonarqube -g {{sonar_user}} {{sonar_user}}

echo "Setting permissions..."
sudo chown -R {{sonar_user}}:{{sonar_user}} /opt/sonarqube

echo "Configuring SonarQube database connection..."
sudo sed -i "s/^#sonar.jdbc.username=/sonar.jdbc.username={{db_user}}/" {{sonarqube_config}}
sudo sed -i "s/^#sonar.jdbc.password=/sonar.jdbc.password={{db_pass}}/" {{sonarqube_config}}
echo "sonar.jdbc.url=jdbc:postgresql://localhost:5432/{{db_name}}" | sudo tee -a {{sonarqube_config}}

echo "SonarQube installation completed!"

Here is a breakdown of what each command in the Install and Configure SonarQube does:

Installs the zip package, which is required for extracting SonarQube files
Downloads the SonarQube package and extracts the SonarQube package into the /opt directory
Renames the extracted folder for easier access
Creates a new user group. Then, creates a new user and assigns them to the new group
Changes ownership of the SonarQube directory to the sonar user
Configures the SonarQube database username and database
Sets the SonarQube database connection URL

Configure System Script

Finally, you create the script to configure the system for SonarQube

Similarly, follow these steps to create the configure system script:

Go to Scripts > New Script
Name: Configure System Script
Add code:

#!/bin/bash

# Exit on any error
set -e

echo "Configuring system limits for SonarQube..."
echo -e "sonarqube   -   nofile   65536\nsonarqube   -   nproc    4096" | sudo tee -a {{limits_config}}

echo "Updating system configuration..."
echo "vm.max_map_count = 262144" | sudo tee -a {{sysctl_config}}
sudo sysctl -p

echo "Creating SonarQube systemd service..."
cat <<EOF | sudo tee {{sonar_service}}
[Unit]
Description=SonarQube service
After=syslog.target network.target

[Service]
Type=forking

ExecStart=/opt/sonarqube/bin/linux-x86-64/sonar.sh start
ExecStop=/opt/sonarqube/bin/linux-x86-64/sonar.sh stop

User=sonar
Group=sonar
Restart=always

LimitNOFILE=65536
LimitNPROC=4096

[Install]
WantedBy=multi-user.target
EOF

echo "Reloading systemd daemon..."
sudo systemctl daemon-reload

echo "Starting and enabling SonarQube service..."
sudo systemctl start sonar
sudo systemctl enable sonar
sudo systemctl status sonar --no-pager

echo "rebooting the server"

echo "System configuration for SonarQube completed!"

This is what the Configure System Script does:

Increases file and process limits for SonarQube to enhance performance
Adjusts kernel memory settings for better performance
Creates a systemd service file for managing SonarQube as a background service
Reloads systemd to recognize the new SonarQube service
Starts the SonarQube service and enables SonarQube to start automatically on boot

Create a Variable Group

Now, before running the scripts, you need to define values for the placeholders {{sonar_user}}, {{db_user}}, {{db_name}}, {{db_user}}, {{db_pass}}, {{sonarqube_config}}, {{limits_config}}, {{sysctl_config}}, {{sonar_service}}, and {{db_postgres_pass}} 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:

sonar_user: Defines the username and group name for the SonarQube service, which is used to run and manage SonarQube securely
db_user: This specifies the PostgreSQL database username for SonarQube
db_name: This sets the name of the PostgreSQL database used by SonarQube
db_pass: The password for the SonarQube database user
db_postgres_pass: Specifies the password for the PostgreSQL postgres superuser account
sonarqube_config: Points to the SonarQube configuration file where database and application settings are stored
limits_config: This specifies the system limits configuration file that controls resource limits for users and processes
sysctl_config: This represents the system configuration file that manages kernel parameters like memory and file descriptor limits
sonar_service: This defines the systemd service file used to manage the SonarQube service as a background process

Since the variables are setup, proceed with running the scripts with CloudRay

Running the Script with CloudRay

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 “SonarQube Deployment Automation and Management”)
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 you need PostgreSQL to be installed
Script Playlist: Choose the playlist you created (For example “SonarQube Deployment Automation and Management”)
Variable Group: Select the variable group you set up earlier

Execute the Script: Click on Run Now to start the execution

Once the script runs successfully, your SonarQube will be fully deployed. You can now visit your SonarQube using your server’s public IP address on port 9000 (https://server-ip-address.com).

Your SonarQube is now deployed and managed with CloudRay. That’s it! Happy deploying!

Troubleshooting

If you encounter issues during deployment, consider the following:

PostgreSQL Installation Fails: Verify repository configuration, GPG key, and postgres user permissions. Check logs with journalctl -u postgresql
SonarQube Fails to Start: Check database credentials in sonar.properties, increase system limits, and ensure port 9000 is free. Use sudo tail -f /opt/sonarqube/logs/sonar.log to monitor logs
Web Interface Inaccessible: Open port 9000 on the firewall, confirm SonarQube is running, and verify the server’s IP or domain

Get Started with CloudRay

Related Guides

How to Deploy phpMyAdmin on Ubuntu

Wed, 19 Mar 2025 00:00:00 GMT

Installing and hardening phpMyAdmin can be a multi-step job which includes setting up packages, configuring web-server rules, enabling SSL, and tightening access controls.

In this tutorial we will automate the whole workflow with CloudRay, turning those steps into a repeatable Bash script. When you are done, you will have a secure phpMyAdmin instance ready for MySQL or MariaDB administration—and you can redeploy it the same way on any server.

Adding Servers to CloudRay
Assumptions
Create the Automation Script
Create a Variable Group
Running the Script with CloudRay
Troubleshooting
Related Guides

Adding Servers to CloudRay

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.

NOTE

This guide uses Bash scripts, providing a high degree of customisation. You can adapt the scripts to fit your specific Installations 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 automate the installation of Nagios, you’ll need three Bash scripts:

Setup MySQL Script: Installs and configures MySQL server, creates a database, and sets up a user with appropriate privileges
Install phpMyAdmin Script: Downloads, installs, and configures phpMyAdmin to provide a web-based interface for managing MySQL databases
Secure phpMyAdmin Script: Implements security measures such as restricting access, setting up authentication, and configuring firewalls to protect the phpMyAdmin instance

Let’s begin with the setting up of MySQL

Setup MySQL Script

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

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

#!/bin/bash

# Exit on error
set -e

# Update system and install MySQL server
sudo dnf update -y
sudo dnf install mysql-server -y

# Start and enable MySQL service
sudo systemctl start mysqld
sudo systemctl enable mysqld

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

echo "✅ MySQL server setup completed successfully!"

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

Updates the system packages to the latest versions
Installs the MySQL server package
tarts MySQL immediately and ensures it starts on boot
Creates a Database and a user
Grants all privileges on the database to the new user
Flushes privileges to apply the changes

IMPORTANT

If you’d like to learn more about managing, backing up, and optimizing your MySQL database, check out our comprehensive guide: How to Deploy & Manage a MySQL Server Using CloudRay.

Install phpMyAdmin Script

Next, you need to create the installation script for phpMyAdmin. To do so, follow similar steps as the above:

Go to Scripts > New Script
Name: Install phpMyAdmin Script
Add code:

#!/bin/bash

# Exit on error
set -e

# Install phpMyAdmin and required PHP extensions
sudo dnf install epel-release -y
sudo dnf install phpmyadmin -y
sudo dnf install php-mysqlnd php-mbstring php-json php-xml php-curl php-zip php-common -y

# Restart Apache
sudo systemctl restart httpd

# Install nano (for manual editing if needed)
sudo dnf install nano -y

# Configure phpMyAdmin access
sudo sed -i 's/Require local/Require all granted/' /etc/httpd/conf.d/phpMyAdmin.conf

# Restart Apache to apply changes
sudo systemctl restart httpd

# Enable external MySQL connections via SELinux
sudo setsebool -P httpd_can_network_connect on

# Install and configure firewall
sudo dnf install firewalld -y
sudo systemctl start firewalld
sudo systemctl enable firewalld
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

echo "✅ phpMyAdmin installation and configuration completed successfully!"

This is what the Install phpMyAdmin Script does:

Enables access to extra packages (including phpMyAdmin) and necessary PHP extensions for phpMyAdmin
Ensures the webserver is running and reloads configurations
Access configuration to allow external access (not just local)
Allows Apache to connect to the MySQL database
Opens HTTP (80) and HTTPS (443) ports for external access

Secure phpMyAdmin Script

To secure your phpMyAdmin instance, follow these steps:

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

#!/bin/bash

# Exit on error
set -e

# Install HTTP authentication tools
sudo dnf install httpd-tools -y

# Create htpasswd file
sudo htpasswd -bc /etc/httpd/.htpasswd {{auth_user}} '{{auth_password}}'

# Allow override for phpMyAdmin in Apache
sudo sed -i '/<Directory \/usr\/share\/phpMyAdmin\/>/,/<\/Directory>/ s/Require all granted/&\n    AllowOverride All/' /etc/httpd/conf.d/phpMyAdmin.conf

# Create .htaccess for phpMyAdmin security
sudo bash -c 'cat <<EOF > /usr/share/phpMyAdmin/.htaccess
AuthType Basic
AuthName "Restricted Access to phpMyAdmin"
AuthUserFile /etc/httpd/.htpasswd
Require valid-user
EOF'

# Restart Apache to apply changes
sudo systemctl restart httpd

# Confirm Apache is running
sudo systemctl status httpd

echo "✅ phpMyAdmin secured successfully!"

Here is a breakdown of what each command in the Secure phpMyAdmin Script does:

Installs the htpasswd command for basic authentication
Creates a new password file (/etc/httpd/.htpasswd)
Enables user authentication via .htaccess
Sets up basic authentication using the credentials stored in /etc/httpd/.htpasswd
Restarts Apache and checks its status

Create a Variable Group

Now, before running the scripts, you need to define values for the placeholders {{db_name}}, {{db_user}}, {{db_password}}, {{auth_user}}, and {{auth_password}} 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 of the database
db_user: The name of the user
db_password: The password of the for the database user
auth_user: The username of your basic authentication for phpMyAdmin
auth_password: The password of your basic authentication for phpMyAdmin

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 deploying and securing phpMyAdmin.

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 phpMyAdmin”)
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 Nagios will be installed
Script Playlist: Choose the playlist you created (For example “Automate Deployment and Management of phpMyAdmin”)
Variable Group: Select the variable group you set up earlier

Execute the Script: Click on Run Now to start the execution

Your phpMyAdmin is now seamlessly deployed and managed with CloudRay. That’s it! Happy deploying!. You can access it by visiting http://<nagios-server-ip>/phpmyadmin

Troubleshooting

If you encounter issues during deployment, consider the following:

phpMyAdmin Web Interface Not Loading: Ensure Apache is running with sudo systemctl status httpd and restart it using sudo systemctl restart httpd. Also, verify that the firewall allows HTTP (port 80) and HTTPS (port 443) traffic.
MySQL Service Not Starting: Check the MySQL service status with sudo systemctl status mysqld and restart it using sudo systemctl restart mysqld. Ensure the service is enabled to start on boot with sudo systemctl enable mysqld
Authentication Issues: If you cannot log in to phpMyAdmin, verify the .htaccess file in /usr/share/phpMyAdmin/ is correctly configured and that the /etc/httpd/.htpasswd file contains the correct credentials

If the issue persists, consult the phpMyAdmin Documentation for further assistance.

Get Started with CloudRay

Related Guides

Deploy a Static Website Without a GitHub Repository

Wed, 12 Mar 2025 00:00:00 GMT

CloudRay provides an automation-friendly approach to deploying static websites on Ubuntu servers, making it a great choice for hosting static sites.

In this guide, you will learn the process of deploying a simple static website(HTML/CSS) using CloudRay. We’ll create an automation Bash script to set up the website structure, configure Caddy as the web server, and deploy the website with a script. By the end, your website will be live on a custom domain with HTTPS support.

NOTE

If you want to learn how to deploy a static website from GitHub using CloudRay, check out our guide on How to Deploy a Static Website From GitHub Using CloudRay.

Adding Servers to CloudRay
Assumptions
Create the Automation Script
- Website Setup Script
- Website Deployment Script
Create a Variable Group
Running the Script with CloudRay
- Run the setup script
- Run the Deployment script
Troubleshooting

Adding Servers to CloudRay

Before getting started with your automation, 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

NOTE

This guide uses Bash scripts, providing a high degree of customisation. You can modify these scripts based on your environment and deployment needs

Assumptions

This guide assumes you’re using Ubuntu 24.04 LTS as your server’s operating system. If you’re using a different version or a different distribution, adjust the commands accordingly.
Your domain name is “mywebsite.com” (replace it with your actual domain)

Create the Automation Script

This guide is ideal for very small projects or quick prototypes. It involves writing HTML and CSS directly in a script.

To simplify deployment, we will create two Bash scripts:

Website Setup Script: This script will create the website structure with HTML and CSS files
Website Deployment Script: This script will install Caddy as a web server and deploy the website

Let’s begin with the simple website setup.

Website Setup Script

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

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

#!/bin/bash

# Exit on error
set -e

# Create website directory
mkdir my-static-website
cd my-static-website

# Create index.html
cat <<EOF > index.html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Greetings from CloudRay</title>
    <link rel="stylesheet" href="styles.css">
</head>
<body>
    <header>
        <h1>Greetings from CloudRay!</h1>
    </header>
    <main>
        <p>This is a simple static website deployed on Ubuntu using CloudRay!</p>
    </main>
    <footer>
        <p>&copy; 2025 My Static Website</p>
    </footer>
</body>
</html>
EOF

# Create styles.css
cat <<EOF > styles.css
body {
    font-family: Arial, sans-serif;
    margin: 0;
    padding: 0;
    background-color: #f4f4f4;
    color: #333;
}

header {
    background-color: #333;
    color: #fff;
    padding: 20px;
    text-align: center;
}

main {
    padding: 20px;
    text-align: center;
}

footer {
    background-color: #333;
    color: #fff;
    text-align: center;
    padding: 10px;
    position: fixed;
    bottom: 0;
    width: 100%;
}
EOF

# Go back to home directory
cd ~


echo "Setup completed!!!"

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

Creates a directory named my-static-website to store the website files
Navigates into the newly created directory
Generates an index.html file with basic HTML content
Creates a styles.css file for styling
Moves back to the home directory after setting up the files

Website Deployment Script

After setting up the simple website, you can deploy the website using Caddy.

Similarly, follow these steps to create the deployment script:

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

#!/bin/bash

# Exit on error
set -e

# install caddy
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update

sudo apt install -y caddy

# Creating the website directory
mkdir -p /var/www

# Copy files to website directory
cp -r my-static-website {{website_dir}}

# Configure Caddyfile
sudo bash -c "cat > {{caddyfile}}" <<EOF
{{your_domain}} {
    root * {{website_dir}}
    file_server
}
EOF

# Grant permission to the server
sudo chown -R www-data:www-data {{website_dir}}
sudo chmod -R 755 {{website_dir}}

# Reload Caddy
sudo systemctl reload caddy

echo "Website deployed! Visit: http://mywebsite.com or https://mywebsite.com"

This is what the Website Deployment Script does:

Installs the necessary dependencies for the Caddy web server, and install Caddy server
Copies the website files from my-static-website to /var/www/my-static-website
Configures Caddy to serve the website using a domain name (mywebsite.com)
Changes ownership of the website directory to www-data (web server user)
Sets permissions to allow public access to the files
Reloads the Caddy server to apply changes

Next, you need to create a variable group and run these scripts using CloudRay.

Create a Variable Group

Now, before running the scripts, you need to define values for the placeholders {{website_dir}}, {{caddyfile}}, and {{your_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:

website-dir: This specifies the directory where the website files are located
caddyfile: This specifies the path to the Caddy web server’s configuration file
your_domain: This specifies your registered domain
your_repo_url: The URL of your GitHub repository (Example, https://github.com/GeoSegun/html-css-website.git)

Since the variables are setup, you can now run the scripts with CloudRay.

Running the Script with CloudRay

You can choose to run the scripts individually or execute them all at once using CloudRay’s Script Playlists. If you prefer to run them individually, follow these steps:

Run the setup script

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

To run the Website Setup Script, 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 “Website Setup Script”
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 Website Setup Script, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Run the Deployment script

After successfully running the Website Setup Script, the next step is to execute the Website Deployment Script using CloudRay’s Runlogs. This script will configure and deploy your website on the server.

To run the Deployment Script, 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: Provide the necessary details:

Server: Select the same server used earlier.
Script: Choose the “Website Deployment Script”.
Variable Group: Select the variable group you created earlier.

Execute the Script: Click on Run Now to deploy your application.

Once the script runs successfully, your application will be fully deployed. You can now visit your application securely using your configured domain (https://yourdomain.com).

Your simple website (HTML/CSS) is now securely deployed and managed with CloudRay. That’s it! Happy deploying!

Troubleshooting

If you encounter issues during deployment, consider the following:

Ensure your domain is properly registered and set the A record to point to your server’s IP address
Verify that all necessary environment variables are correctly set on your CloudRay variable Group

Get Started with CloudRay

Deploy a Static Website From a GitHub Repository

Tue, 11 Mar 2025 00:00:00 GMT

CloudRay simplifies the process of deploying static websites directly from a GitHub repository. This method is ideal for larger projects or teams, as it allows you to maintain version control and collaborate seamlessly. In this guide, you’ll learn how to clone a GitHub repository containing your website files, configure Caddy as the web server, and deploy your site with CloudRay’s automation-friendly tool.

By the end, your static website will be live on a custom domain with automatic HTTPS support.

NOTE

If you want to deploy a static website without using GitHub, follow our guide on How to Deploy a Static Website Without a GitHub Repository Using CloudRay.

Adding Servers to CloudRay
Assumptions
Create a Static Website Deployment Script
Running the Script with CloudRay
Related Guides

Adding Servers to CloudRay

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

NOTE

This guide uses Bash scripts, providing a high degree of customisation. You can modify these scripts based on your environment and deployment needs

Assumptions

This guide assumes you’re using Ubuntu 24.04 LTS as your server’s operating system. If you’re using a different version or a different distribution, adjust the commands accordingly.
Your domain name is “mywebsite.com” (replace it with your actual domain)

Create a Static Website Deployment Script

You need to create a script to deploy a static website from your GitHub repository. Follow these steps to achieve this:

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

#!/bin/bash

set -e

# Install Caddy
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update

sudo apt install -y caddy

# Create the website directory
mkdir -p /var/www

# Clone or update the GitHub repository
if [ -d "{{website_dir}}/.git" ]; then
    echo "Updating existing repository..."
    cd "{{website_dir}}"
    git fetch --all
    git reset --hard origin/main
else
    echo "Cloning repository..."
    git clone "{{your_repo_url}}" "{{website_dir}}"
fi

# Configure Caddyfile
sudo bash -c "cat > {{caddyfile}}" <<EOF
{{your_domain}} {
    root * {{website_dir}}
    file_server
}
EOF

# Grant permission to the server
sudo chown -R www-data:www-data "{{website_dir}}"
sudo chmod -R 755 "{{website_dir}}"

# Reload Caddy
sudo systemctl reload caddy

echo "Website deployed! Visit: http://{{your_domain}} or https://{{your_domain}}"

This updated script clones your GitHub repository (or pulls the latest changes if it already exists), configures Caddy to serve the website, and deploys it to your server. Each time you run the script, it ensures your website is synced with the latest changes from the main branch.

Running the Script with CloudRay

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

NOTE

Ensure you use the same variables from the Deploy a Static Website Without a GitHub Repository Using CloudRay.

You can choose to run the scripts individually or execute them all at once using CloudRay’s Script Playlists. If you prefer to run them individually, 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 “Static Website Deployment Script”
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 Static Website Deployment Script, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Your static website hosted on GitHub is now successfully deployed on the server! You can visit it by navigating to your configured domain (e.g., http://mywebsite.com or https://mywebsite.com).

Get Started with CloudRay

Related Guides

How to Monitor Remote Hosts with Nagios

Fri, 07 Mar 2025 00:00:00 GMT

IMPORTANT

Before implementation, make sure you have Nagios deployed on a separate server. However, if you want to automate the installation of Nagios, follow our guide on How to Automate the Installation of Nagios.

After setting up Nagios, you can extend its capabilities by monitoring remote hosts. This guide covers how to use CloudRay to automate configuring a remote Linux host and the Nagios server to track key metrics such as system load, active processes, and SSH status.

Adding Servers to CloudRay
Assumptions
Setup NRPE on Remote Server
Configure Nagios Server to Monitor Remote Server
Running the Scripts with CloudRay
- Run the Setup NRPE Script
- Configure Nagios Script

Adding Servers to CloudRay

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

NOTE

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

Assumptions

This guide assumes your Nagios is deployed already on Rocky Linux 9 and the Remote server to Monitor is using Ubuntu 24.04 LTS as your server’s operating system. If you’re using a different version or a different distribution, adjust the commands accordingly

Setup NRPE on Remote Server

To monitor a remote host, start by setting up NRPE on the remote-server. Create a new script in CloudRay:

Go to Scripts → New Script
Name it Setup NRPE Script
Add the following script:

#!/bin/bash

# Exit on error
set -e

# Update system packages
sudo apt update

# Install Nagios NRPE server and plugins
sudo apt install -y nagios-nrpe-server nagios-plugins nagios-plugins-basic nagios-nrpe-plugin


sudo sed -i "s/^allowed_hosts=.*/allowed_hosts=127.0.0.1,::1,{{nagios_server_ip}}/" /etc/nagios/nrpe.cfg

# Start and enable the NRPE service
sudo systemctl start nagios-nrpe-server
sudo systemctl enable nagios-nrpe-server
sudo systemctl status nagios-nrpe-server --no-pager

# Check UFW status and configure firewall rules
sudo ufw status
sudo ufw allow ssh
yes | sudo ufw enable
sudo ufw allow 5666/tcp
sudo ufw reload

echo "Nagios NRPE setup completed successfully!"

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

Updates all installed packages
Installs NRPE and the necessary Nagios plugins
Configures NRPE to accept connections from the nagios-server IP address.
Starts and enables the NRPE service

Configure Nagios Server to Monitor Remote Server

After setting up NRPE on the remote server, you need to configure the Nagios server to monitor it.

You can follow similar steps as the above:

Go to Scripts → New Script
Name it Configure Nagios Script
Add the following script:

#!/bin/bash

# Exit on error
set -e

# Install NRPE plugin and nano
sudo dnf install -y nagios-plugins-nrpe nano

# Update commands.cfg to define check_nrpe command
sudo bash -c 'cat <<EOF >> /usr/local/nagios/etc/objects/commands.cfg

define command {
    command_name check_nrpe
    command_line /usr/lib64/nagios/plugins/check_nrpe -H \$HOSTADDRESS\$ -c \$ARG1\$
}
EOF'

# Open firewall for NRPE port
sudo firewall-cmd --add-port=5666/tcp --permanent
sudo firewall-cmd --reload

# Update hosts.cfg with contact, host, and service definitions
sudo bash -c 'cat <<EOF >> /usr/local/nagios/etc/objects/hosts.cfg

define contact {
    use                     generic-contact
    contact_name            {{nagios_user}}
    alias                   {{nagios_alias}}
    email                   {{nagios_email}}
}

define host {
    use                     linux-server
    host_name               nagios-example
    address                 {{remote_server_ip}}
    max_check_attempts      5
    check_period            24x7
    notification_interval   30
    notification_period     24x7
}

define service {
    use                     generic-service
    host_name               nagios-example
    service_description     SSH
    check_command           check_ssh
    max_check_attempts      3
    check_interval          2
    retry_interval          1
}

define service {
    use                    generic-service
    host_name              nagios-example
    service_description    System Load
    check_command          check_nrpe!check_load
    max_check_attempts     5
    check_interval         2
    retry_interval         1
}

define service {
    use                    generic-service
    host_name              nagios-example
    service_description    Total Processes
    check_command          check_nrpe!check_total_procs
    max_check_attempts     5
    check_interval         2
    retry_interval         1
}
EOF'

# Add hosts.cfg reference in nagios.cfg
sudo bash -c 'echo "cfg_file=/usr/local/nagios/etc/objects/hosts.cfg" >> /usr/local/nagios/etc/nagios.cfg'

# Restart Nagios to apply changes
sudo systemctl restart nagios

echo "Nagios server configuration for remote host completed successfully!"

Here is a breakdown of what each command in the Configure Nagios Script does:

Installs the nagios-plugins-nrpe package (which includes the NRPE plugin for remote checks) and nano for editing
Adds a check_nrpe command definition to the Nagios commands.cfg file to allow remote checks via NRPE
Configures the system firewall to allow incoming TCP traffic on port 5666 (used by NRPE) and reloads firewall settings
Updates the hosts.cfg configuration file
Adds a reference to the hosts.cfg file in the main Nagios configuration (nagios.cfg) if not already present
Restarts the Nagios service to apply all configuration changes

Running the Scripts with CloudRay

You can automate this entire process using CloudRay by executing the scripts on both the nagios-server and remote-server.

NOTE

Ensure you use the same variables from the Nagios installation process. This ensures consistency across your Nagios monitoring setup. Follow our detailed guide on Automate the Installation of Nagios Using CloudRay for reference.

You can choose to run the scripts individually or execute them all at once using CloudRay’s Script Playlists. If you prefer to run them individually, follow these steps:

Run the Setup NRPE Script

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

To run the Setup NRPE Script, 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 “Setup NRPE Script”
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 Setup NRPE Script, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Configure Nagios Script

Next, you need to run the second script to configure the Nagios server to monitor it.

To run the Configure Nagios Script, follow similar 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: Provide the necessary details:

Server: Select the same server used earlier.
Script: Choose the “Configure Nagios Script”.
Variable Group: Select the variable group you created earlier.

Execute the Script: Click on Run Now to deploy your application.

After executing the scripts, you verify the Nagios web interface (http://<nagios-server-ip>/nagios) to confirm the new remote host is being monitored successfully.

How to Automate the Installation of Nagios

Thu, 06 Mar 2025 00:00:00 GMT

Automating the installation of Nagios on Rocky Linux 9 ensures consistency, reduces errors, and saves time when setting up monitoring for your environment. CloudRay, enables seamless setup, deployment, and management of Nagios. By leveraging CloudRay, you can automate the setting up, configurations, and deployment of Nagios.

In this guide, you will learn how to automate the installation of Nagios Core on Rocky Linux 9 using CloudRay.

IMPORTANT

This article focuses on installing Nagios Core on Rocky Linux 9 using CloudRay. If you’re looking to monitor remote hosts using NRPE, check out our companion guide: How to Monitor Remote Hosts with Nagios Using CloudRay

Adding Servers to CloudRay
Assumptions
Create the Automation Script
- Setup Nagios Script
- Deploy Nagios Script
Create a Variable Group
Running the Scripts to Install Nagios with CloudRay
Troubleshooting
Related Guide

Adding Servers to CloudRay

Before getting started with your automation, 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

NOTE

This guide uses Bash scripts, providing a high degree of customisation. You can adapt the scripts to fit your specific Installations 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 automate the installation of Nagios, you’ll need two Bash scripts:

Setup Nagios Script: Installs the necessary dependencies and configures Nagios Core
Deploy Nagios Script: Sets up the web interface, enables Nagios, and configures the firewall

Let’s begin with the setting up of Nagios

Setup Nagios Script

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

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

#!/bin/bash

# Exit on error
set -e

# Update system packages
sudo dnf update -y

# Install required dependencies
sudo dnf install tar nano gcc glibc glibc-common wget perl net-snmp openssl-devel make unzip gd gd-devel epel-release httpd php php-cli php-common php-gd -y

# Create a directory for Nagios and navigate to it
cd ~
mkdir nagios
cd nagios

# Download Nagios Core
wget https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.5.9.tar.gz

# Ensure tar is installed
sudo dnf install tar -y

# Extract Nagios
tar -xvf nagios-4.5.9.tar.gz
cd nagios-4.5.9

# Configure and compile Nagios
./configure
make all

# Create Nagios user and groups
sudo make install-groups-users
sudo usermod -a -G nagios apache

# Install Nagios and its components
sudo make install
sudo make install-init
sudo make install-commandmode
sudo make install-config
sudo make install-webconf

# Verify Nagios configuration
sudo /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

echo "Nagios core setup completed successfully!"

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

Updates all installed packages to the latest version
Installs essential packages like gcc, nano, wget, perl, httpd, and php
Creates and navigates to a directory for Nagios installation
Downloads Nagios Core (version 4.5.9 in this case) and Extracts the Nagios archive
Configures and compiles Nagios
Creates the nagios user and group and adds the apache user to the nagios group for web interface access
Install Nagios components, including the core configuration, init scripts, and web interface

Deploy Nagios Script

Next, you need to create the deployment script for Nagios. To do so, follow similar steps as the above:

Go to Scripts > New Script
Name: Deploy Nagios Script
Add code:

#!/bin/bash

# Exit on error
set -e

# Create Nagios admin user
sudo htpasswd -cb /usr/local/nagios/etc/htpasswd.users {{nagios_user}} {{nagios_password}}

# Set proper permissions
sudo chown apache:nagios /usr/local/nagios/etc/htpasswd.users

# Start and enable Nagios
sudo systemctl start nagios
sudo systemctl enable nagios

# Confirm Nagios is running
sudo systemctl status nagios --no-pager

# Install and configure FirewallD
sudo dnf install firewalld -y
sudo systemctl start firewalld
sudo systemctl enable firewalld

# Open HTTP port
sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --reload

# Enable and restart services
sudo systemctl enable httpd
sudo systemctl restart nagios httpd

# Install Nagios plugins
cd ~/nagios/
wget https://nagios-plugins.org/download/nagios-plugins-2.4.11.tar.gz
tar -xvf nagios-plugins-2.4.11.tar.gz
cd nagios-plugins-2.4.11

./configure
make
sudo make install

# Final restart
sudo systemctl restart nagios httpd

echo "Nagios deployment completed successfully!"

This is what the Deploy Nagios Script does:

Creates a Nagios web admin user with the password
Ensures Apache and Nagios have the right permissions
Starts, enables, and checks the status of the Nagios service
Installs the firewall and opens port 80 for HTTP traffic
Downloads and installs Nagios plugins for additional monitoring capabilities
Restarts Nagios and the web server to apply changes

Create a Variable Group

Now, before running the scripts, you need to define values for the placeholders {{nagios-user}}, {{nagios-password}}, {{nagios-alias}}, {{nagios-email}}, {{nagios-server-ip}}, and {{remote-server-ip}} 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:

nagios-user: This is the Nagios username
nagios-password: This is the Nagios password
nagios-alias: This is the Nagios alias
nagios-email: The email of the Nagios account
nagios-server-ip: The IP Address of the Nagios Server
remote-server-ip: The IP Address of the remote server to be monitored

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

Running the Scripts to Install Nagios with CloudRay

Now that everything is setup, you can use CloudRay to automate the installation of Nagios.

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 “Nagios Deployment Automation and Management”)
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 Nagios will be installed
Script Playlist: Choose the playlist you created (For example “Nagios Deployment Automation and Management”)
Variable Group: Select the variable group you set up earlier

Execute the Script: Click on Run Now to start the execution

Your Nagios is now seamlessly deployed and managed with CloudRay. That’s it! Happy deploying!. You can access it by visiting http://<nagios-server-ip>/nagios

Troubleshooting

If you encounter issues during deployment, consider the following:

Nagios Web Interface Not Loading: Ensure Apache is running with sudo systemctl status httpd and restart it using sudo systemctl restart httpd
Nagios Service Not Starting: Check the service status with sudo systemctl status nagios and restart it using sudo systemctl restart nagios

If the issue persists, consult the Nagios Core Documentation for further assistance.

Get Started with CloudRay

Related Guide

How to Deploy Jenkins with Docker Compose

Wed, 05 Mar 2025 00:00:00 GMT

CloudRay provides a flexible automation framework to deploy and manage infrastructure and applications. Using CloudRay, you can automate the provisioning of essential services like Jenkins using Docker and Docker Compose, enabling seamless CI/CD pipeline setups. This guide walks through deploying Jenkins using Docker Compose and configuring Caddy as a reverse proxy for improved security and ease of access.

By the end of this article, you will have a fully functional Jenkins instance running in Docker, exposed securely via Caddy, and automated through CloudRay.

Adding Servers to CloudRay
Assumptions
Create the Automation Script
Create a Variable Group
Running the Script with CloudRay
Troubleshooting
Related Guides

Adding Servers to CloudRay

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.

NOTE

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

Assumptions

This guide assumes you’re using Ubuntu 24.04 LTS 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 and management processes, you’ll need three Bash scripts:

Install Docker and Docker Compose: This script will installs Docker and Docker Compose, adds a new user for Docker management, and sets up Docker to run on startup
Set up Docker Compose for Jenkins: This script sets up a Docker Compose configuration for Jenkins and starts the service
Install and Configure Caddy: This script will installs Caddy, sets up a reverse proxy for Jenkins, and ensures Caddy runs on system boot

Install Docker and Docker Compose

To create the install Docker and Docker Compose script, you need to follow these steps:

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

#!/bin/bash

# Stop executing the script if any of the commands fail
set -e

# Update package lists and install required dependencies
sudo apt-get update
sudo apt-get install ca-certificates curl -y

# Add Docker's official GPG key
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add Docker repository to Apt sources
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Update package lists and install Docker packages
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

# Create a new user "user" with the password "kali"
sudo adduser --gecos "" --disabled-password user
echo "user:{{user_password}}" | sudo chpasswd

# Add "user" to the docker group for Docker permissions
sudo usermod -aG docker user

# Restart and enable Docker service
sudo systemctl restart docker
sudo systemctl enable docker

# Download Docker Compose binary
mkdir bin
cd /bin
wget https://github.com/docker/compose/releases/download/v2.28.1/docker-compose-linux-x86_64 -O docker-compose
chmod +x docker-compose

# Add Docker Compose to PATH if not already present
if ! grep -q 'export PATH="${HOME}/bin:${PATH}"' ~/.bashrc; then
    echo 'export PATH="${HOME}/bin:${PATH}"' >> ~/.bashrc
    source ~/.bashrc
fi

echo "Docker and Docker Compose installation completed successfully!"

Below is a breakdown of what each command in the Install Docker and Docker Compose does:

Ensures the system has the required packages for Docker installation
Allows secure installation from Docker’s official repository
Installs the latest Docker engine, CLI tools, and Compose
Creates a user named with password and grants Docker access
Enables and starts Docker to ensure it runs on system boot
Downloads and configures Docker Compose for container orchestration

Setup Docker Compose for Jenkins

After the installation of Docker and Docker Compose, you create a script to sets up a Docker Compose configuration for Jenkins and start the service.

Similarly, follow these steps to setup Docker Compose for Jenkins:

Go to Scripts > New Script
Name: Setup Docker Compose for Jenkins
Add code:

#!/bin/bash

# Stop executing the script if any of the commands fail
set -e

# Create the Jenkins Docker Compose directory
mkdir -p ~/jenkins-compose
cd ~/jenkins-compose

# Create the docker-compose.yml file
cat <<EOL > docker-compose.yml
version: '3.8'
services:
  jenkins:
    container_name: jenkins
    restart: always
    image: jenkins/jenkins:lts
    ports:
      - 8080:8080
    volumes:
      - jenkins-home:/var/jenkins_home

volumes:
  jenkins-home:
EOL

# Enable and start Docker service
sudo systemctl enable docker.service
sudo systemctl start docker.service

# Start Jenkins using Docker Compose
docker-compose up -d

This is what the Setup Docker Compose for Jenkins does:

Sets up a dedicated directory for the Jenkins deployment
Defines the Jenkins service with persistent storage
Ensures Docker is running and Jenkins starts automatically
Uses Docker Compose to run Jenkins in detached mode

Install and Configure Caddy

After setting up Docker Compose for Jenkins, you can secure the deployment using Caddy.

To create the script, you need to follow these steps:

Go to Scripts in your CloudRay project
Click New Script
Name: Install and Configure Caddy
Copy this code:

#!/bin/bash

# Stop executing the script if any of the commands fail
set -e

#!/bin/bash

# Install prerequisites for Caddy
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https

# Add Caddy's official GPG key and repository
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list

# Update package lists and install Caddy
sudo apt update
sudo apt install caddy -y

# Set up the Caddyfile to reverse proxy to Jenkins
sudo bash -c 'cat <<EOL > {{caddyfile}}
{{your_domain}} {
    reverse_proxy localhost:8080
}
EOL'

# Validate and reload Caddy configuration
sudo caddy validate --config {{caddyfile}}
sudo systemctl reload caddy
sudo systemctl status caddy

Below is a breakdown of what each command in the Install and Configure Caddy does:

Downloads and installs the Caddy web server
Ensures the installation is secure and from an official source
Creates a reverse proxy configuration to expose Jenkins externally
Checks for syntax errors and reloads the Caddy service

Create a Variable Group

Before running the scripts, you need to define values for the placeholders {{user_password}}, {{caddyfile}}, and {{your_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:

your_domain: This specifies your registered domain
caddyfile: This specifies the path to the Caddy web server’s configuration file
user_password: The password of the docker user

Running the Script with CloudRay

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 “Jenkins Deployment Automation and Management”)
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 Jenkins will be installed
Script Playlist: Choose the playlist you created (For example “Jenkins Deployment Automation and Management”)
Variable Group: Select the variable group you set up earlier

Execute the Script: Click on Run Now to start the execution

Your Jenkins is now successfully deployed and managed by CloudRay. That’s it! Happy deploying!

You can use the command (docker exec -it jenkins cat /var/jenkins_home/secrets/initialAdminPassword) to retrieve the Administrator password.

Troubleshooting

If you encounter issues during deployment, consider the following:

Jenkins service not starting: Ensure Docker is running by checking sudo systemctl status docker and restart if necessary
Permission issues: Ensure the user has Docker permissions by verifying membership in the docker group with groups user
Caddy reverse proxy not working: Verify the Caddyfile configuration and ensure your domain points to the server’s IP address
Unable to access Jenkins UI: Check if ports 8080 (Jenkins) and 80/443 (Caddy) are open in your firewall
Caddy service failing: Validate the Caddyfile with sudo caddy validate --config /path/to/Caddyfile and check logs with sudo journalctl -u caddy

Get Started with CloudRay

Related Guides

How to Automate the Installation of Apache Airflow

Wed, 26 Feb 2025 00:00:00 GMT

CloudRay, a cloud automation platform, allows you to automate the installation and configuration of Apache Airflow using Bash scripts, ensuring a seamless and repeatable deployment process.

In this guide, we will walk through the steps to install and configure Apache Airflow on an Ubuntu 24.04 server using CloudRay. This guide covers:

Writing automation script for installing Airflow, configuring it, and setting up a reverse proxy with Caddy
Running the scripts on a remote server using CloudRay

By the end of this article, you will have a fully functional Apache Airflow setup, accessible through a web UI, and ready to run your workflows.

Adding Servers to CloudRay
Assumptions
Create the Automation Script
Create a Variable Group
Running the Script with CloudRay
Troubleshooting
Related Guide

Adding Servers to CloudRay

Before getting started with your automation, 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

NOTE

This guide uses Bash scripts, providing a high degree of customisation. You can modify these scripts based on your environment and deployment needs

Assumptions

This guide assumes you’re using Ubuntu 24.04 LTS 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 automate the installation of Apache Airflow, you will use four Bash scripts:

Installation and Setup Script: This script will install required dependencies, sets up the PostgreSQL database, and install Apache Airflow
Airflow Configuration Script: This script will configures Airflow’s database connection and initializes it
Start Airflow Script: This script create an admin user and starts the Airflow services
Install and Configure Caddy Script: This script will installs and configures Caddy as a reverse proxy

Let’s begin with the installation and configuration of Apache Airflow.

Creating Installation and Setup Script

To create the installation and setup script, you need to follow these steps:

Go to Scripts in your CloudRay project
Click New Script
Name: Install and setup Apache Airflow. You can give it any name of your choice
Copy this code:

#!/bin/bash

# Exit immediately if a command exits with a non-zero status
set -e

# Update system packages
sudo apt update

# Install required packages
sudo apt install -y python3 python3-venv python3-dev gcc libpq-dev postgresql postgresql-contrib

# Start and enable PostgreSQL
sudo systemctl start postgresql
sudo systemctl enable postgresql

# Create Airflow database and user
sudo -u postgres psql <<EOF
CREATE USER {{db_user}} PASSWORD '{{db_pass}}';
CREATE DATABASE {{db_name}};
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO {{db_user}};
ALTER DATABASE {{db_name}} OWNER TO {{db_user}};
GRANT ALL ON SCHEMA public TO {{db_user}};
EOF

# Setup Python virtual environment
python3 -m venv airflow_env
source ~/airflow_env/bin/activate

# Install Airflow and PostgreSQL connector
pip install --upgrade pip
pip install psycopg2-binary apache-airflow[postgres]

echo "Installation and setup completed"

Here is a breakdown of what each command in the Install and setup Apache Airflow does:

Updates system packages
Installs Python and PostgreSQL dependencies starts, and enables PostgreSQL
Creates an Airflow database and user
Sets up a Python virtual environment
Installs Apache Airflow and PostgreSQL connector

If you’re looking to back up or manage your Airflow database effectively, check out our PostgreSQL guide.

Apache Airflow Configuration Script

After the installation and setup of Airflow, you need to configure its settings

Similarly, follow these steps to setup the database:

Go to Scripts > New Script
Name: Configure Airflow Script
Add code:

#!/bin/bash

set -e

# Activate virtual environment
source ~/airflow_env/bin/activate

# Initialize Airflow DB
airflow db init

sed -i 's/executor = SequentialExecutor/executor = LocalExecutor/' {{airflow_cgf}}
sed -i 's|sql_alchemy_conn = sqlite:////root/airflow/airflow.db|sql_alchemy_conn = postgresql+psycopg2://{{db_user}}:{{db_pass}}@localhost/{{db_name}}|' {{airflow_cgf}}

# Reinitialize Airflow DB
airflow db init

echo "Airflow configured successfully"

This is what the Configure Airflow Script does:

Activates the Python virtual environment
Initializes the Airflow database
Modifies the Airflow configuration file to use LocalExecutor instead of the default SequentialExecutor
Updates the database connection to use PostgreSQL

Start Apache Service Script

Moving forward, you need to start Airflow and create an admin user. Here, you follow similar steps as the previous ones to create the backup script:

Go to Scripts > New Script
Name: Start Apache Service Script
Add code:

#!/bin/bash

set -e

# Activate virtual environment
source ~/airflow_env/bin/activate

# Create an Airflow admin user
airflow users create \
   --username {{username}} \
   --password {{password}} \
   --firstname {{firstname}} \
   --lastname {{lastname}} \
   --role Admin \
   --email {{email}}

# Start Airflow services in the background
nohup airflow webserver -p 8080 > webserver.log 2>&1 &
nohup airflow scheduler > scheduler.log 2>&1 &

echo "Airflow started successfully."

This is what the Start Apache Service Script does:

Activates the virtual environment
Creates an admin user for Airflow
Starts the Airflow webserver and scheduler in the background

Install and Configure Caddy Script

After starting the Airflow service, you can configure caddy server as a reverse proxy and secure the domain. This ensures airflow runs on port 80/443 with HTTPS enabled.

Similarly, follow these steps to create the installation and configuration script:

Go to Scripts > New Script
Name: Install and Configure Caddy Script
Add code:

#!/bin/bash

set -e

# Install Caddy
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

# Configure Caddy
echo "airflow.example.com {
    reverse_proxy localhost:8080
}" | sudo tee /etc/caddy/Caddyfile

# Validate and start Caddy
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl start caddy
sudo systemctl enable caddy

echo "Caddy installed and configured. You can access Airflow at http://airflow.example.com or https://airflow.example.com"

This is what the Install and Configure Caddy Script does:

Installs Caddy from the official repository
Configures it as a reverse proxy for Airflow
Starts and enables the Caddy service

Create a Variable Group

Now, before running the scripts, you need to define values for the placeholders {{db_name}}, {{db_user}}, {{db_pass}}, {{airflow_cgf}}, {{username}}, {{password}},{{firstname}}, {{lastname}} 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:

airflow_cfg: This is the file path to Airflow’s configuration file, which contains settings for the Airflow environment
db_name: This is the name of the database used to store Airflow’s metadata and operational data
db_user: The username for accessing the Airflow database
db_pass: The password for the database user to authenticate and access the Airflow database
username: This is the username for the default admin account in the Airflow web interface
password: This is the password for the default admin account to log in to the Airflow web interface
firstname: This is the first name associated with the default admin account in Airflow
lastname: The last name associated with the default admin account in Airflow
email: The email address associated with the default admin account, used for notifications and alerts

Since the variables are setup, proceed with running the scripts with CloudRay.

Running the Script with CloudRay

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 Installation and Configuration of Airflow”)
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 you need Apache Airflow to be installed
Script Playlist: Choose the playlist you created (For example “Automate Installation and Configuration of Airflow”)
Variable Group: Select the variable group you set up earlier

Execute the Script: Click on Run Now to start the execution

Your Apache Airflow is now installed, setup, and managed with CloudRay. That’s it! Happy deploying!

Troubleshooting

If you encounter issues during deployment, consider the following:

Ensure your domain is properly registered and set the A record to point to your server’s IP address.
Verify that all necessary environment variables are correctly set on your CloudRay variable Group

Get Started with CloudRay

Related Guide

Automate the Installation of K3s

Sat, 22 Feb 2025 00:00:00 GMT

Setting up a Kubernetes cluster manually can be repetitive and error-prone. This guide walks you through automating the installation of K3s, configuring the cluster, and deploying tools like Helm and the NVIDIA GPU Operator, all using Bash scripts executed through CloudRay.

Whether you’re building a lightweight production cluster or a test environment, the process becomes faster, consistent, and easier to manage

Adding Servers to CloudRay
Assumptions
Create the Automation Script
- Install and Configure Cluster Script
- Install Helm and Deploy NVIDIA Script
Create a Variable Group
Running the Script with CloudRay
- Run the Install cluster script
- Run the Install and Deploy NVIDIA script
Troubleshooting
Related Guide

Adding Servers to CloudRay

Before getting started with your automation, 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

NOTE

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

Assumptions

This guide assumes you’re using Ubuntu 24.04 LTS as your server’s operating system. If you’re using a different version or a different distribution, adjust the commands accordingly
You intend to deploy K3s as a single-node cluster. If using a multi-node setup, additional steps such as node joining must be performed
Your server has NVIDIA drivers installed if you plan to use GPU workloads

Create the Automation Script

To automate the installation, you’ll need two Bash scripts:

Install and Configure Cluster Script: This script will installs K3s and configures the environment
Install Helm and Deploy NVIDIA Script: This script will installs Helm and deploys the NVIDIA GPU Operator

Let’s begin with the installation and configuration of the cluster.

Install and Configure Cluster Script

To create the Install and Configure Cluster Script, you need to follow these steps:

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

#!/bin/bash

# Exit on error
set -e

# Install K3s
echo "Installing K3s..."
curl -sfL https://get.k3s.io | sh -

# Create kubeconfig directory
mkdir -p {{kubeconfig_dir}}

# Symlink K3s config
ln -sf /etc/rancher/k3s/k3s.yaml {{kubeconfig_dir}}/config

# Set permissions
sudo chmod 755 {{kubeconfig_dir}}/config

# Allow necessary ports through UFW
echo "Configuring firewall rules..."
sudo ufw allow 6443/tcp
sudo ufw allow 30000:32767/tcp
sudo ufw allow 30000:32767/udp

# Enable K3s service
echo "Enabling K3s service..."
sudo systemctl enable k3s
sudo systemctl status k3s --no-pager

echo "K3s installation completed!"

Here is a breakdown of what each command in the Install and Configure Cluster Script does:

Installs K3s using the official installation script
Creates and configures the Kubernetes configuration directory
Opens required ports in the firewall
Enables and starts the K3s service

Install Helm and Deploy NVIDIA Script

If you plan to run GPU-accelerated workloads, you can install Helm and deploy the NVIDIA GPU Opertor.

Similarly, follow these steps to deploy NVIDIA:

Go to Scripts > New Script
Name: Install Helm and Deploy NVIDIA Script
Add code:

#!/bin/bash

# Exit on error
set -e

# Install Helm
echo "Installing Helm..."
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# Add NVIDIA Helm repository
echo "Adding NVIDIA repository..."
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

# Export KUBECONFIG
export KUBECONFIG={{kubeconfig_dir}}/config

# Install GPU Operator
echo "Deploying NVIDIA GPU Operator..."
helm install --wait gpu-operator nvidia/gpu-operator --create-namespace -n gpu-operator --set driver.enabled=false

echo "GPU Operator installation completed!"

This is what the Install Helm and Deploy NVIDIA Script does:

Installs Helm, a package manager for Kubernetes
Adds the NVIDIA Helm repository and updates it
Deploys the NVIDIA GPU Operator to enable GPU workloads in K3s

Create a Variable Group

Now, before running the scripts, you need to define values for the placeholders {{kubeconfig_dir}} 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:

kubeconfig_dir: This is the path where kubernetes configuration files are stored

Since the variables is setup, proceed with running the scripts with CloudRay

Running the Script with CloudRay

You can choose to run the scripts individually or execute them all at once using CloudRay’s Script Playlists. If you prefer to run them individually, follow these steps:

Run the Install cluster script

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

To run the Install and Configure Cluster Script, 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 “Install and Configure Cluster Script”
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 Install and Configure Cluster Script, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

Run the Install and Deploy NVIDIA script

However, if you wish to run GPU-accelerated workloads, you can run the Install Helm and Deploy NVIDIA Script.

To run the Install Helm and Deploy NVIDIA Script, follow similar 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: Provide the necessary details:

Server: Select the same server used earlier.
Script: Choose the “Install Helm and Deploy NVIDIA Script”.
Variable Group: Select the variable group you created earlier.

Execute the Script: Click on Run Now to deploy your application.

Your lightweight Kubernetes cluster with K3s is now deployed and ready for GPU-accelerated workloads with the NVIDIA GPU Operator!

Troubleshooting

If you encounter issues during deployment, consider the following:

K3s Service Not Running: Check service status with sudo systemctl status k3s and restart with sudo systemctl restart k3s
Firewall Issues: Verify that required ports (6443, 30000-32767) are open using sudo ufw status
NVIDIA GPU Operator Deployment Issues: Check logs with kubectl logs -n gpu-operator -l app=nvidia-gpu-operator

If you still experience issues, refer to the official K3s Guide and NVIDIA GPU Operator Documentation for more details.

Get Started with CloudRay

Related Guide

How to Deploy & Manage a MySQL Server

Thu, 20 Feb 2025 00:00:00 GMT

In this article, you will learn how to deploy and manage MySQL server on Ubuntu 24.04 using CloudRay, an automation tool that simplifies server management. This guide will cover setting up MySQL, configuring it for remote access, creating a database with a user, implementing automated backups, and executing these tasks using CloudRay.

The deployment strategy involves:

The installation and configuration of MySQL Server
Creating databases, user, and sample table
Automating Database backups

By the end of this article, you will have a fully functional MySQL server deployed on Ubuntu 24.04, managed seamlessly through CloudRay automation.

Adding Servers to CloudRay
Assumptions
Create the Automation Script
- Installation and Configuration Script
- Database setup Script
Create a Variable Group
Running the Script with CloudRay
Scheduling MySQL Database Backup with CloudRay’s Schedules (Optional)
Related Guides

Adding Servers to CloudRay

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.

NOTE

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

Assumptions

This guide assumes you’re using Ubuntu 24.04 LTS 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 and management processes, you’ll need three Bash scripts:

Installation and Configuration Script: This script will install MySQL, secure it, and configure it for remote access.
Database setup Script: This script will Creates a MySQL database, user, and a sample table.
Backup Script: This script will automate the backup processes for MySQL database

Installation and Configuration Script

To create the Installation and configuration script, you need to follow these steps:

Go to Scripts in your CloudRay project
Click New Script
Name: Install and Configure MySQL Server. You can give it any name of your choice.
Copy this code:

#!/bin/bash

# Stop executing the script if any of the commands fail
set -e

# Update system package lists
sudo apt update

# Install MySQL Server
sudo apt install -y mysql-server

# Secure MySQL Installation
printf "y\n2\ny\ny\ny\ny\n" | sudo mysql_secure_installation

# Modify or add port configuration
sudo sed -i "s/^port\s*=.*/port = 5231/" {{mysql_conf}}

# Check if bind-address exists, modify it; otherwise, add it
if grep -q "^bind-address" {{mysql_conf}}; then
    sudo sed -i "s/^bind-address\s*=.*/bind-address = 0.0.0.0/" {{mysql_conf}}
else
    echo "bind-address = 0.0.0.0" | sudo tee -a {{mysql_conf}}
fi

# Restart MySQL to apply changes
sudo systemctl restart mysql

echo "MySQL configuration updated successfully!"

Below is a breakdown of what each command in the Install and Configure MySQL Server does:

Updates the system’s package list to ensure that the latest versions of software packages are installed
Installs the latest version of MySQL Server
Secures MySQL by setting a strong password, removing anonymous users, disallowing remote root login, and deleting test databases
Changes the default MySQL port to 5231 and enabling remote connections by setting bind-address = 0.0.0.0
Restarts MySQL to apply the changes

Database setup Script

After the installation of MySQL, you need to create a MySQL database, a dedicated user with privileges, and a table if necessary.

Similarly, follow these steps to setup the database:

Go to Scripts > New Script
Name: Setup MySQL Database
Add code:

#!/bin/bash

set -e

# Enter MySQL and execute commands
sudo mysql <<EOF
CREATE DATABASE IF NOT EXISTS {{db_name}};
CREATE USER IF NOT EXISTS '{{db_user}}'@'%' IDENTIFIED BY '{{db_pass}}';
GRANT ALL PRIVILEGES ON {{db_name}}.* TO '{{db_user}}'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

USE {{db_name}};
CREATE TABLE IF NOT EXISTS students (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    age INT NOT NULL,
    department VARCHAR(100) NOT NULL
);

EOF

echo "Database {{db_name}}, user {{db_user}}, and students table created successfully!"

This is what the Setup MySQL Database does:

Creates the database if it doesn’t exist
Creates a MySQL user with a specified password
Grants full privileges to the user on the database
Reloads privileges to apply changes
Creates the students table with columns for id, name, age, and department (you can adjust this based on your need)

Create a Variable Group

Before running the scripts, you need to define values for the placeholders {{mysql_conf}}, {{db_name}}, {{db_user}} {{db_pass}}, and {{backup_dir}} 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:

mysql_conf: This is the Bash variable that stores the file path of the MySQL configuration file
db_name: This is the name of the database
db_user: The name of the user
db_pass: The password of the for the database user
backup_dir: The directory where MySQL database backups will be stored

Running the Script with CloudRay

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 “MySQL Deployment Automation and Management”)
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 MySQL will be installed
Script Playlist: Choose the playlist you created (For example “MySQL Deployment Automation and Management”)
Variable Group: Select the variable group you set up earlier

Execute the Script: Click on Run Now to start the execution

Your MySQL Server is now seamlessly deployed and managed with CloudRay. That’s it! Happy deploying!

Scheduling MySQL Database Backup with CloudRay’s Schedules (Optional)

CloudRay also offers Schedules, allowing you to execute scripts automatically at specific intervals or times. This feature is useful for tasks such as automating database backups.

To automate MySQL database backups with CloudRay, you first need to create a backup script that the scheduler will execute.

You can follow similar steps as the previous ones to create the backup script:

Go to Scripts > New Script
Name: Backup MySQL Database
Add code:

#!/bin/bash

set -e

BACKUP_FILE="{{backup_dir}}/{{db_name}}_$(date +%F_%H-%M-%S).sql"

# Ensure backup directory exists
mkdir -p {{backup_dir}}

# Perform database backup
sudo mysqldump -u root {{db_name}} > $BACKUP_FILE

# Confirm backup success
if [ $? -eq 0 ]; then
    echo "Backup successful: $BACKUP_FILE"
else
    echo "Backup failed!"
    exit 1
fi

This is what the Setup MySQL Database does:

Ensures the backup directory exists
Backs up the database to a timestamped file
Checks if the backup was successful: If successful, it prints the backup path; otherwise, it reports failure and exits with an error code.

For example, if you want to back up your database on the first day of every month at 12:00 AM, you can configure a CloudRay schedule to handle this automatically.

Here are the steps to achieve this:

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 database is regularly backed up without manual intervention.

Get Started with CloudRay

Related Guides

Setting Up a PostgreSQL Database on a Remote Server

Mon, 17 Feb 2025 00:00:00 GMT

Setting up a PostgreSQL database on a remote server can be time-consuming, but automation tools like CloudRay simplify the process. CloudRay allows you to automate server configurations, setup, and database management through scripting.

In this guide, we will walk you through setting up a PostgreSQL database on a remote Ubuntu server using CloudRay. You will learn how to add the server to CloudRay, automating PostgreSQL installation and configuration, creating a database and user, and scheduling backups.

By the end of this article, you will have a fully functional PostgreSQL instance that is automated and easily manageable by CloudRay.

Adding Servers to CloudRay
Assumptions
Create the Automation Script
- Installation and Configuration Script
- Database Setup Script
Create a Variable Group
Running the Script with CloudRay
Scheduling PostgreSQL Database Backup with CloudRay’s Schedules (Optional)
Related Guides

Adding Servers to CloudRay

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

NOTE

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

Assumptions

This guide assumes you’re using Ubuntu 24.04 LTS 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 setup and management processes, you’ll need three Bash scripts:

Installation and Configuration Script: This script will install PostgreSQL and modifies its configuration files accordingly
Database setup Script: This script will creates a PostgreSQL database, user, and a sample table
Backup Script: This script will automate the backup processes for PostgreSQL database

Let’s begin with the installation and configuration of PostgreSQL.

Installation and Configuration Script

To create the Installation and configuration script, you need to follow these steps:

Go to Scripts in your CloudRay project
Click New Script
Name: Install and Configure PostgreSQL Database. You can give it any name of your choice.
Copy this code:

#!/bin/bash

# Exit immediately if a command exits with a non-zero status
set -e

# Update package lists
sudo apt update -y

# Install PostgreSQL without interactive prompts
sudo apt install -y postgresql postgresql-contrib

# Start and enable PostgreSQL service
sudo systemctl start postgresql
sudo systemctl enable postgresql

# Modify postgresql.conf to allow external connections
sudo sed -i "s/^#listen_addresses = 'localhost'/listen_addresses = '*' /" {{postgres_conf}}

# Enable logging for PostgreSQL
echo "logging_collector = on" | sudo tee -a {{postgres_conf}}
echo "log_directory = '/var/log/postgresql'" | sudo tee -a {{postgres_conf}}
echo "log_filename = 'postgresql-%Y-%m-%d.log'" | sudo tee -a {{postgres_conf}}
echo "log_rotation_age = 1d" | sudo tee -a {{postgres_conf}}
echo "log_rotation_size = 10MB" | sudo tee -a {{postgres_conf}}

# Modify pg_hba.conf to allow remote access with password authentication
echo "host    all             all             0.0.0.0/0               md5" | sudo tee -a {{pg_hba_conf}}
echo "host    all             all             ::/0                    md5" | sudo tee -a {{pg_hba_conf}}

# Reload PostgreSQL to apply authentication changes
sudo systemctl reload postgresql

# Restart PostgreSQL to apply changes
sudo systemctl restart postgresql

echo "PostgreSQL installed and configured successfully."

Here is a breakdown of what each command in the Install and Configure PostgreSQL Database does:

Updates package lists to ensure we install the latest versions
Installs the latest version of PostgreSQL and additional components
Starts and enables PostgreSQL to ensure it runs on system startup
Modifies postgresql.conf to allow external connections
Enables logging for PostgreSQL to store logs in /var/log/postgresql and rotate them daily or when they exceed 10MB
Modifies pg_hba.conf to enforce password authentication for all remote connections (both IPv4 and IPv6)
Reloads PostgreSQL to apply authentication changes without restarting the database
Restarts PostgreSQL to apply changes

Database Setup Script

After the installation and configuration of PostgreSQL, you set up the postgreSQL database by creating a Postgres database, a dedicated user with privileges, and a table if necessary.

Similarly, follow these steps to setup the database:

Go to Scripts > New Script
Name: Setup Postgres Database
Add code:

#!/bin/bash

set -e

# Create the user and database
sudo -u postgres psql <<EOF
CREATE USER {{db_user}} PASSWORD '{{db_pass}}';
CREATE DATABASE {{db_name}};
GRANT ALL PRIVILEGES ON DATABASE {{db_name}} TO {{db_user}};
ALTER DATABASE {{db_name}} OWNER TO {{db_user}};
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO {{db_user}};
GRANT ALL ON SCHEMA public TO {{db_user}};
CREATE TABLE UserGrades (
    Name VARCHAR(100),
    Grade VARCHAR(50)
);
EOF

echo "PostgreSQL database {{db_name}} with user {{db_user}} created successfully."

This is what the Setup Postgres Database does:

Switches to the postgres user and runs SQL commands
Creates a new PostgreSQL user
Creates a new database
Grants full access to the database
Assigns ownership of the database to the user
Grants table permissions
Creates a sample table

Create a Variable Group

Now, before running the scripts, you need to define values for the placeholders {{postgres_conf}}, {{pg_hba_conf}}, {{db_name}}, {{db_user}}, and {{db_pass}} 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:

postgres_conf: This is the Bash variable that stores the file path of the PostgreSQL configuration file
pg_hba_conf: This is the Bash variable that stores the file path of the PostgreSQL Host-Based Authentication (HBA) configuration file
db_name: This is the name of the database
db_user: The name of the user
db_pass: The password of the for the database user

Since the variables are setup, proceed with running the scripts with CloudRay

Running the Script with CloudRay

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 “PostgreSQL Setup Automation and Management”)
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 you need PostgreSQL to be installed
Script Playlist: Choose the playlist you created (For example “PostgreSQL Setup Automation and Management”)
Variable Group: Select the variable group you set up earlier

Execute the Script: Click on Run Now to start the execution

Your PostgreSQL is now seamlessly setup and managed with CloudRay. That’s it! Happy deploying!

Scheduling PostgreSQL Database Backup with CloudRay’s Schedules (Optional)

CloudRay also offers Schedules, allowing you to execute scripts automatically at specific intervals or times. This feature is useful for tasks such as automating database backups.

To automate PostgreSQL database backups with CloudRay, you first need to create a backup script that the scheduler will execute.

You can follow similar steps as the previous ones to create the backup script:

Go to Scripts > New Script
Name: Backup Postgres Database
Add code:

#!/bin/bash

set -e

BACKUP_FILE="{{db_name}}_$(date +%F_%H-%M-%S).sqlc"

# Create .pgpass file for authentication
PGPASS_FILE="$HOME/.pgpass"
echo "localhost:5432:{{db_name}}:{{db_user}}:{{db_pass}}" > "$PGPASS_FILE"
chmod 600 "$PGPASS_FILE"

echo "Performing database backup..."

# Perform database backup
pg_dump -h localhost -U "{{db_user}}" -d "{{db_name}}" -p 5432 -F c -f "$BACKUP_FILE"

# Confirm backup success
if [ $? -eq 0 ]; then
    echo "Backup successful: $BACKUP_FILE"
else
    echo "Backup failed!"
    exit 1
fi

This is what the Setup Postgres Database does:

Defines the path for PostgreSQL authentication
Stores database credentials
Secures the credentials file
Creates a backup of the database in compressed format
Checks if the backup was successful: If successful, it prints the backup path; otherwise, it reports failure and exits with an error code.

For example, if you want to back up your database on the first day of every month at 12:00 AM, you can configure a CloudRay schedule to handle this automatically.

Here are the steps to achieve this:

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 database is regularly backed up without manual intervention.

Get Started with CloudRay

Related Guides

Deploy Delayed Jobs with Bash scripts

Sat, 18 Jan 2025 00:00:00 GMT

This guide provides a step-by-step approach to deploying Delayed Jobs for your Ruby on Rails application using Bash scripts and CloudRay. It is intended as a supplement to the main Deploy Ruby on Rails app with Bash scripts guide.

Prerequisites

This guide assumes you have followed the main Rails deployment guide and have already:

Set up a CloudRay account.
Added your server to CloudRay.
Created the server-setup and deploy-rails-app scripts.
Created a variable group with the necessary variables.

Update the setup script

You’ll need to update the server-setup script to include a systemd service for Delayed Jobs. This service will ensure that Delayed Jobs runs in the background and restarts automatically if it fails.

Open the server-setup script: In your CloudRay project, navigate to “Scripts” and edit the server-setup script.
Add the following code at the end of the script:

# Install a systemd service to run Delayed Job
cat <<'EOT' > /etc/systemd/system/{{app_name}}-delayed-job.service
[Unit]
Description={{app_name}}-delayed-job
After=network.target

[Service]
Type=simple
User=deploy
EnvironmentFile=/etc/environment
WorkingDirectory=/srv/{{app_name}}
ExecStart=/bin/bash -c "PATH=/home/deploy/.asdf/bin:/home/deploy/.asdf/shims:$PATH asdf exec bundle exec bin/delayed_job start -p {{app_name}} -i 0 --queues=mailers,default --pool=5"
Restart=always
StandardOutput=file:/srv/{{app_name}}/log/delayed_job-stdout.log
StandardError=file:/srv/{{app_name}}/log/delayed_job-stderr.log

[Install]
WantedBy=multi-user.target
EOT

Modify the deployment script

You’ll also need to modify the deploy-rails-app script to restart the Delayed Job service after each deployment. This ensures that Delayed Job picks up the latest code changes.

Open the deploy-rails-app script: In your CloudRay project, navigate to “Scripts” and edit the deploy-rails-app script.
Add the following line after the systemctl restart {{app_name}}-puma.service line:

systemctl restart {{app_name}}-delayed-job.service

Run the updated scripts

Now that you’ve updated the server-setup script, you need to run it again to apply the changes. After that, you can run the deploy-rails-app script to deploy your Rails application and start Delayed Job.

Follow these steps:

Run the server-setup script: Create a new Runlog for the server-setup script, just like you did in the main Rails deployment guide. This will create the systemd service for Delayed Job.
Run the deploy-rails-app script: Once the server setup is complete, create a new Runlog for the deploy-rails-app script. This will deploy your Rails application and start the Delayed Job worker.

That’s it! Your Delayed Jobs worker is now set up and will be automatically deployed with your Rails application.

How to create a GitHub Access Token for deployment

Fri, 17 Jan 2025 00:00:00 GMT

This guide explains how to create a GitHub fine-grained Personal Access Token that you can use for deployments. This token allows CloudRay to securely clone your repositories during the deployment process.

Steps to create a token

Go to GitHub Settings:
- Log in to your GitHub account
- Click your profile picture in the top right
- Select “Settings”
Navigate to Developer Settings:
- Scroll to the bottom of the left sidebar
- Click “Developer settings”
Access Personal Access Tokens:
- Select “Fine-grained tokens”
- Click “Generate new token”
Configure the token:
- Name: Give your token a descriptive name (e.g., “CloudRay Deployments”)
- Expiration: Choose an expiration date (recommended: 1 year)
- Repository access: Select “Only select repositories” and choose your deployment repositories
- Permissions:
  - Repository permissions:
    - “Contents”: Read-only (needed for cloning)
    - “Metadata”: Read-only (required by default)
Generate and copy the token:
- Click “Generate token”
- Important: Copy the token immediately. GitHub will only show it once.

Using the token

When setting up your CloudRay variable group for deployments:

Create a variable named github_access_token
Paste your GitHub token as the value

The token will be used in the format: https://{token}@github.com/{username}/{repo} when cloning repositories.

Organization requirements

If your repository belongs to an organisation:

The organisation must allow fine-grained tokens
An organisation owner needs to enable fine-grained tokens:
- Go to Organization Settings > Third-party Access > Personal Access Tokens
- Click “Set organisation token policy”
- Enable “Allow fine-grained personal access tokens”

Security considerations

Never share your token or commit it to your repository
Use the minimum required permissions
Regularly rotate your tokens by creating new ones and deleting old ones
If a token is compromised, revoke it immediately in your GitHub settings

Token expiration

When your token expires:

Create a new token following the steps above
Update the github_access_token variable in your CloudRay variable group
The old token will automatically become invalid after expiration

That’s it! Your GitHub fine-grained Access Token is now ready to use with CloudRay deployment scripts.

Deploy Express & Node on Ubuntu 24.04

Sat, 04 Jan 2025 00:00:00 GMT

Deploy your Express.js application seamlessly with CloudRay. This guide walks you through setting up and automating the deployment process, ensuring your app is always up-to-date.

Adding Servers to CloudRay
Assumptions
Create the setup script
Create the Deployment Script
Create a Variable Group
Run the setup script
Run the deployment script
Related Guides

Adding Servers to CloudRay

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.

NOTE

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

Assumptions

This guide assumes that the database is hosted on a separate server. Installing and configuring the database on the same server as the Rails application is not within the scope of this document. You can refer to other articles for instructions on setting up a database server.
This guide assumes you’re using Ubuntu 24.04 LTS as your server’s operating system. If you’re using a different version or a different distribution, adjust the commands accordingly.

Once your server is added, proceed to the next step.

Create the setup script

To streamline the deployment process, you’ll need two Bash scripts:

Setup Script: You’ll run this once when setting up a new server to install dependencies and configure services.
Deployment Script: You can run this anytime you want to update your application with new code.

In this section, we’ll create the Setup Script.

The setup script prepares your server by:

Creating a deploy user that runs the Node server using pm2 as a non-privileged service
Installing Caddy web server for automatic HTTPS
Setting up asdf to install Node.js
Creating a systemd service to start pm2 at boot
Setting up the repository for the first time

To create the setup script:

Go to Scripts in your CloudRay project
Click New Script
Name: Setup Express Server
Copy this code:

# Stop executing the script if any of the commands fail
set -e

# Create a deploy user if it doesn't exist
# This is the user that will run the Express app
if [ ! -d /home/deploy ]; then
  echo "Creating deploy user"
  adduser --disabled-password --gecos "" deploy
fi

# We'll deploy the Express app to /srv
# Let's ensure the deploy user has the right permissions
echo "Setting up /srv directory"
chown deploy:deploy -R /srv

# Install the essential packages
echo "Installing essential packages"
export DEBIAN_FRONTEND=noninteractive
apt-get update
apt-get install -y git caddy

echo "Configuring Caddy to serve the Express app"
cat > /etc/caddy/Caddyfile <<'EOT'
{{app_domain}} {
  reverse_proxy localhost:{{express_port}}
}
EOT

# We'll install asdf to manage node version
su -l deploy <<'EOT'
  set -e
  if [ ! -d "$HOME/.asdf" ]; then
    echo "Installing asdf"
    git clone https://github.com/asdf-vm/asdf.git ~/.asdf
    echo "source $HOME/.asdf/asdf.sh" >> ~/.bashrc
  else
    echo "Updating asdf"
    cd ~/.asdf
    git pull
  fi

  source $HOME/.asdf/asdf.sh

  if ! grep -q "legacy_version_file" ~/.asdfrc; then
    echo "legacy_version_file = yes" >> ~/.asdfrc
  fi
  asdf plugin add nodejs
  echo "Installing Node.js version {{node_version}}"
  asdf install nodejs {{node_version}}
  asdf reshim
  asdf global nodejs {{node_version}}
  npm install -g pm2
  echo "Finished installing Node.js"
EOT

echo "Creating the pm2 startup service"
export ASDF_DIR=/home/deploy/.asdf
export ASDF_DATA_DIR=/home/deploy/.asdf
source /home/deploy/.asdf/asdf.sh
asdf shell nodejs {{node_version}}
pm2 startup systemd -u deploy --hp /home/deploy

echo "Setting up the repository for the first time"
su -l deploy <<'EOT'
  set -e
  source "$HOME/.asdf/asdf.sh"
  mkdir -p /srv/{{app_name}}
  cd /srv/{{app_name}}
  if [ ! -d "/srv/{{app_name}}/.git" ]; then
    git clone https://{{github_access_token}}@github.com/{{github_repo_name}} .
  fi
  npm install
  pm2 stop {{app_name}} || true
  env PATH="$(asdf where nodejs)/bin:$PATH" pm2 start npm --name {{app_name}} -- start
  pm2 save
EOT

systemctl restart caddy.service

echo "Done."

TIP

If you find this script too long to manage, you can break it into smaller scripts and use Script Playlists to run them together.

Create the Deployment Script

You’ll use this script whenever you want to update your application. The script:

Pulls latest code from your Git repository’s main branch
Installs app dependencies
Restarts the Node server using pm2

To create the deployment script:

Go to Scripts > New Script
Name: Deploy Express App
Add code:

set -e

su -l deploy <<'EOT'
set -e
. "$HOME/.asdf/asdf.sh"
cd /srv/{{app_name}}
git fetch --all
git reset --hard origin/main
npm install
pm2 restart {{app_name}}
EOT

echo "🚀 Deployed {{app_name}} at https://{{app_domain}}"

Create a Variable Group

Our scripts use variables like {{app_name}}, {{app_domain}}, and {{node_version}} because CloudRay processes all scripts as Liquid templates. This allows you to use placeholders in your scripts, making them dynamic and reusable across different servers.

To provide values for these variables, you’ll need to create a variable group. Here’s how:

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 “New Variable Group”.
Add the following variables:

app_name: Your application’s name (use underscores instead of spaces), e.g., my_app
app_domain: Your application’s domain name, e.g., myapp.example.com
node_version: The version of Node.js you want to install. E.g., 20.0.0
express_port: The port your Express application listens on (e.g., 3000)
github_access_token: Your GitHub personal access token for cloning the repository.
github_repo_name: Your GitHub repository in the format username/repository, e.g., yourusername/your-repo.

Run the setup script

To run the Setup Express Server script, you’ll use a Runlog in CloudRay. A Runlog allows you to execute scripts on your servers and provides detailed logs of the execution process.

Here’s how to create and run a Runlog:

Navigate to Runlogs: In your CloudRay project, go to “Runlogs” in the top menu.
Create a new Runlog: Click on “New Runlog”.
Fill in the form:

Server: Select the server you added earlier.
Script: Choose the Setup Express Server script.
Variable Group: Select the variable group you created earlier.

Run the script: Click on “Run” to execute the script on your server.

CloudRay will connect to your server, run the Setup Express Server script, and show you the live output as the script executes.

Run the deployment script

You can run the deploy-rails-app script whenever you want to deploy a new version of your application. Here’s how to create a Runlog for the deployment script:

Navigate to Runlogs: In your CloudRay project, go to “Runlogs” in the top menu.
Create a new Runlog: Click on “New Runlog”.
Fill in the form:

Server: Select the server you added earlier.
Script: Choose the Deploy Express App script.
Variable Group: Select the variable group you created earlier.

Run the script: Click on “Run” to execute the script on your server.

CloudRay will connect to your server, run the Deploy Express App script, and show you the live output as the script executes.

That’s it! Happy deploying!

Get Started with CloudRay

Related Guides

Deploy Ruby on Rails app on Ubuntu 24.04

Thu, 02 Jan 2025 00:00:00 GMT

This guide walks through automating Rails deployments with CloudRay. You will configure Puma, Caddy and ASDF to create a production environment where updates deploy with a single command, handling code updates, dependencies, assets and migrations automatically.

The setup runs under a dedicated deploy user with systemd for process management, while Caddy provides HTTPS and static file serving. All infrastructure is defined in reusable Bash scripts, making your deployment process consistent and version-controlled.

This guide focuses on deploying Rails applications with Puma. For deploying background workers (e.g., Delayed Jobs), refer to our Deploy Deplayed Jobs guide.

Adding Servers to CloudRay
Assumptions
Create the setup script
Create the deployment script
Create a variable group
Run the setup script
Run the deployment script
Troubleshooting
- Running out of memory when installing Ruby
Related Guides

Adding Servers to CloudRay

Before getting started, make sure your target servers are connected to CloudRay. If you have not done this yet, follow our servers docs 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 deployment needs and environment.

Assumptions

This guide assumes that the database is hosted on a separate server. Installing and configuring the database on the same server as the Rails application is not within the scope of this document. For database setup, see our PostgreSQL, MySQL, or MongoDB guides.
This guide assumes you’re using Ubuntu 24.04 LTS as your server’s operating system. If you’re using a different version or a different distribution, adjust the commands accordingly.

Create the setup script

To streamline the deployment process, you’ll need two Bash scripts:

Setup Script: You’ll run this once when setting up a new server to install dependencies and configure services.
Deployment Script: You can run this anytime you want to update your application with new code.

In this section, we’ll create the Setup Script.

The setup script prepares your server by:

Creating a deploy user that runs Rails server as a non-privileged service
Installing Caddy web server for automatic HTTPS
Setting up asdf to install Ruby and Node.js
Creating a systemd service to manage the Rails server
Setting up the repository for the first time

To create the setup script:

Go to Scripts in your CloudRay project
Click New Script
Name: setup-rails-server
Copy this code:

# Stop executing the script if any of the commands fail
set -e

# Create a deploy user if it doesn't exist
# This is the user that will run the Rails application
if [ ! -d /home/deploy ]; then
  echo "Creating deploy user"
  adduser --disabled-password --gecos "" deploy
fi

# We'll deploy the Rails app to /srv
# let's ensure the deploy user has the right permissions
echo "Setting up /srv directory"
chown deploy:deploy -R /srv

# Update the server
echo "Updating the server"
export DEBIAN_FRONTEND=noninteractive
apt-get update
apt-get dist-upgrade -y

echo "Installing essential packages"
apt-get install -y git caddy

# Additional packages for Nokogiri
echo "Installing additional packages for Ruby & Nokogiri"
apt-get install -y build-essential patch zlib1g-dev liblzma-dev libyaml-dev libreadline-dev libffi-dev

# Remove these lines if you don't need MySQL libraries for the mysql gem
echo "Installing packages for mysql2"
apt-get install -y libmysqlclient-dev

# Remove these lines if you don't need PostgreSQL libraries for the pg gem
echo "Installing packages for pg"
apt-get install -y libpq-dev

echo "Configuring Caddy to serve the Rails application"
cat > /etc/caddy/Caddyfile <<'EOT'
{{app_domain}} {
  root * /srv/{{app_name}}/public
  encode zstd gzip
  file_server
  @notStatic not file
  reverse_proxy @notStatic unix//srv/{{app_name}}/tmp/puma.sock
}
EOT

su -l deploy <<'EOT'
  set -e
  if [ ! -d "$HOME/.asdf" ]; then
    echo "Installing asdf"
    git clone https://github.com/asdf-vm/asdf.git ~/.asdf
    echo "source $HOME/.asdf/asdf.sh" >> ~/.bashrc
  else
    echo "Updating asdf"
    cd ~/.asdf
    git pull
  fi

  source $HOME/.asdf/asdf.sh

  if ! grep -q "legacy_version_file" ~/.asdfrc; then
    echo "legacy_version_file = yes" >> ~/.asdfrc
  fi
  asdf plugin add ruby
  asdf plugin add nodejs
  echo "Installing Ruby version {{ruby_version}}"
  asdf install ruby {{ruby_version}}
  echo "Installing Node.js version {{node_version}}"
  asdf install nodejs {{node_version}}
  asdf reshim
  echo "Finished installing Ruby and Node.js"
EOT

echo "Creating the {{app_name}}-rails-server service"
cat <<'EOT' > /etc/systemd/system/{{app_name}}-rails-server.service
[Unit]
Description={{app_name}}-rails
After=network.target

[Service]
Type=simple
User=deploy
Environment=RAILS_ENV=production
EnvironmentFile=/etc/environment
WorkingDirectory=/srv/{{app_name}}
ExecStart=/bin/bash -lc "source $HOME/.asdf/asdf.sh && rails server -b /srv/{{app_name}}/tmp/puma.sock"
Restart=always

[Install]
WantedBy=multi-user.target
EOT

echo "Enabling the {{app_name}}-rails-server service"
systemctl enable {{app_name}}-rails-server.service

echo "Setting up the repository for the first time"
su -l deploy <<'EOT'
  set -e
  source "$HOME/.asdf/asdf.sh"
  mkdir -p /srv/{{app_name}}
  cd /srv/{{app_name}}
  if [ ! -d "/srv/{{app_name}}/.git" ]; then
    git clone https://{{github_access_token}}@github.com/{{github_repo_name}} .
  fi
EOT

echo "Done."

TIP

If you find this script too long to manage, you can break it into smaller scripts and use Script Playlists to run them together.

Create the deployment script

You’ll use this script whenever you want to update your application. Here is what the script does:

Pulls latest code from your Git repository’s main branch
Updates Ruby dependencies and installs new gems
Precompiles JavaScript/CSS assets for production
Runs any pending database migrations safely
Restarts the Rails server

To create the deployment script:

Go to Scripts > New Script
Name: deploy-rails-app
Add code:

set -e

su -l deploy <<'EOT'
set -e
. "$HOME/.asdf/asdf.sh"
cd /srv/{{app_name}}
git fetch --all
git reset --hard origin/main
bundle
echo "{{rails_master_key}}" > config/master.key
RAILS_ENV=production bundle exec rails assets:precompile
RAILS_ENV=production bundle exec rails db:migrate
EOT

echo "Restarting processes"
systemctl restart {{app_name}}-rails-server.service

echo "🚀 Deployed {{app_name}} at {{app_domain}}"

Create a variable group

Our scripts use variables like {{app_name}}, {{app_domain}}, {{ruby_version}}, and {{node_version}} because CloudRay processes all scripts as Liquid templates. This allows you to use placeholders in your scripts, making them dynamic and reusable across different servers.

To provide values for these variables, you’ll need to create a variable group. Here’s how:

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 “New Variable Group”
Add the following variables:

app_name: Your application’s name (use underscores instead of spaces), e.g., my_app
app_domain: Your application’s domain name, e.g., myapp.example.com
ruby_version: The version of Ruby you want to install. E.g., 3.4.3
node_version: The version of Node.js you want to install. E.g., 23.10.0
rails_master_key: Your Rails master key from config/master.key.
github_access_token: Your GitHub personal access token for cloning the repository.
github_repo_name: Your GitHub repository in the format username/repository, e.g., yourusername/your-repo.

Run the setup script

To run the setup-rails-server script, you’ll use a Runlog in CloudRay. A Runlog allows you to execute scripts on your servers and provides detailed logs of the execution process.

Here’s how to create and run a Runlog:

Navigate to Runlogs: In your CloudRay project, go to “Runlogs” in the top menu.
Create a new Runlog: Click on “New Runlog”.
Fill in the form:

Server: Select the server you added earlier.
Script: Choose the setup-rails-server script.
Variable Group: Select the variable group you created earlier.

Run the script: Click on “Run” to execute the script on your server.

CloudRay will connect to your server, run the setup-rails-server script, and show you the live output as the script executes.

Run the deployment script

You can run the deploy-rails-app script whenever you want to deploy a new version of your application. Here’s how to create a Runlog for the deployment script:

Navigate to Runlogs: In your CloudRay project, go to “Runlogs” in the top menu.
Create a new Runlog: Click on “New Runlog”.
Fill in the form:

Server: Select the server you added earlier.
Script: Choose the deploy-rails-app script.
Variable Group: Select the variable group you created earlier.

Run the script: Click on “Run” to execute the script on your server.

CloudRay will connect to your server, run the deploy-rails-app script, and show you the live output as the script executes.

Troubleshooting

Running out of memory when installing Ruby

If you encounter an “out of memory” error during the Ruby installation using asdf install ruby, it’s likely because the /tmp directory is mounted in RAM with limited space. The build process requires more space than is available in the RAM-mounted /tmp.

To resolve this issue, you can disable the RAM mount for /tmp so it uses disk storage instead.

Create a new script with following code and run it on your server:

set -e
echo "Disable mounting /tmp in RAM otherwise ruby-build will run out of memory"
systemctl mask tmp.mount
reboot

That’s it! Happy deploying!

Get Started with CloudRay

CloudRay Articles

Top Cron Job Alternatives for Modern Engineering Team in 2026

Contents

When Cron Still Works Perfectly

Built-in Cron Unix-like Alternative Tools

Top Modern Cron Job Alternatives in 2026

1. ActiveBatch

2. CloudRay

3. Apache Airflow

4. Rundeck

5. Stonebranch

6. VisualCron

7. Celery

8. Sidekiq

9. Kubernetes CronJobs

10. Jenkins

11. GitHub Actions

12. HashiCorp Nomad

How to Choose the Right Cron Alternative

Conclusion

Why Cron Jobs Fail Silently in Production and How to Fix It

Contents

Common Causes of Silent Cron Failures and How to Fix Them

1. Cron Doesn’t Use Your Shell Environment

2. Cron Uses /bin/sh Not Bash

3. Cron Output Is Being Discarded

4. Permissions and Ownership Issues

5. Relative Paths Break Under Cron

6. Missing Environment Variables

7. You’re Editing the Wrong Crontab

8. The Cron Daemon Isn’t Running

9. Long-Running Jobs Overlap and Kill Each Other

10. Cron Jobs Inside Docker Aren’t Running at All

11. Failure to Add Error Logging

How CloudRay Helps You Avoid Silent Cron Failures

What is Configuration Drift and How to Eliminate It

Contents

What is configuration drift?

Common configuration drift scenarios

Causes of configuration drift

Strategies for eliminating configuration drift

Wrapping up

How to Deploy Your VitePress Site

Contents

Adding Servers to CloudRay

Create a Deployment Script

Define the Variable Group

Run the Deployment Script

Next Step

Summary

Configuration Management vs Infrastructure as Code Explained

Contents

What is Configuration Management?

Benefits of Configuration Management

What is Infrastructure as Code (IaC)?

Benefits of Infrastructure as Code

Differences Between IaC and Configuration Management

When to Use Each Approach

The Middle Ground: Centralised Script Management

How to Deploy Your Jekyll Site

Contents

Adding Servers to CloudRay

Create a Deployment Script

Define the Variable Group

Run the Deployment Script

Next Step

Summary

Bash vs Python for DevOps - Which is Better for Automation

Contents

What is Bash in DevOps

What is Python in DevOps

Head-to-head comparison: Bash vs Python

When to use Bash in DevOps automation

When to use Python in DevOps automation

Conclusion

How to Deploy Your Eleventy Site

Contents

Adding Servers to CloudRay

Create a Deployment Script

Define the Variable Group

2. Cron Uses `/bin/sh` Not Bash