Forem: Phaustin Karani

AWS IAM Security Best Practices in 2026: A Complete Guide

Phaustin Karani — Sat, 07 Mar 2026 06:01:00 +0000

Identity is the new perimeter.

Before cloud-native infrastructure, security teams could draw a physical boundary around their systems. Today, your perimeter is a set of credentials — and attackers know it.

AWS Identity and Access Management (IAM) is the backbone of access control in AWS. It answers two fundamental questions: who can access your cloud environment (developers, SREs, CI/CD pipelines, third-party services), and what they can do once inside (read an S3 bucket, invoke a Lambda function, spin up an EC2 instance).

Get IAM wrong, and a single compromised credential can cascade into a full account takeover. Get it right, and you've closed off the most common attack vector in cloud breaches.

This guide covers the IAM security best practices every team should have in place in 2026 — from foundational hygiene to advanced guardrails.

📘 Want hands-on practice? This article covers the why — if you want to master the how, check out Learn AWS Identity Management with AWS IAM, SSO & Federation on Udemy. It covers AWS IAM, Organizations, Directory Service, SSO, and Federation end-to-end, fully updated for 2026.

1. Use Federated Identity for Human Access

Never create long-term IAM users for human access.

Instead, require all humans — developers, SREs, data engineers, auditors — to authenticate through a federated identity provider (IdP) such as Okta, Azure AD, Google Workspace, or AWS IAM Identity Center (formerly AWS SSO).

Why federation matters:

Centralized user management: Onboarding and offboarding happens in one place. When an employee leaves, disabling their IdP account revokes access to all connected systems instantly.
Reduced password fatigue: Users authenticate once and access multiple systems through SSO, reducing the temptation to reuse passwords.
Smaller attack surface: Fewer systems store credentials, meaning fewer places for attackers to target.
Audit-ready logs: Federated sessions tie CloudTrail events back to a specific identity in your IdP, making forensic investigation and compliance reporting straightforward.

Federated users receive short-lived, automatically expiring session tokens — not permanent access keys. This dramatically reduces the blast radius of any single credential compromise.

2026 note: AWS IAM Identity Center now supports automated provisioning (SCIM) with all major IdPs. If your team hasn't migrated off IAM users for human access yet, this is the year to do it.

2. Enforce Multi-Factor Authentication (MFA)

MFA is non-negotiable.

It combines something you know (your password) with something you have (a TOTP app, hardware key, or passkey). Even if a password is phished or leaked in a breach, MFA prevents it from being used alone.

Enforce MFA on:

The root account — always, without exception
All IAM users with console access (if you still have any)
Highly privileged roles and break-glass accounts
Sensitive operations like disabling CloudTrail or modifying SCP policies

You can enforce MFA conditions in IAM policies like this:

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}

For privileged accounts, use hardware security keys (FIDO2/WebAuthn, e.g., YubiKey). Unlike TOTP apps, they are fully phishing-resistant.

3. Protect and Restrict the Root User

Your AWS root user has unrestricted access to everything — billing, account settings, IAM itself — and cannot be constrained by IAM policies. That makes it uniquely dangerous.

Root user hygiene checklist:

Enable MFA immediately, preferably with a hardware key
Store credentials in a secrets vault or a physically secured location
Never create access keys for the root user
Only use it for the small set of tasks that require it, like closing the account or changing the support plan
Set up a CloudWatch or GuardDuty alert to notify your team any time the root user is used at all

In multi-account AWS Organizations setups, use Service Control Policies (SCPs) to block sensitive actions by member account root users.

4. Apply the Principle of Least Privilege

Grant every identity — human or machine — the minimum permissions required for its specific job, and nothing more.

This limits what an attacker can do if they compromise a credential. It also limits damage from insider threats and misconfigured automation.

Practical steps:

Start with AWS managed policies, then refine with customer-managed policies as access patterns become clearer
Use IAM Access Analyzer's policy generation to analyze CloudTrail logs and generate a minimal policy based on what a role actually used
Prefer resource-level permissions (specific bucket ARNs, function ARNs) over wildcard * resources
Avoid AdministratorAccess except for dedicated break-glass roles
Scope iam:PassRole tightly — it's one of the most common privilege escalation paths

Permission boundaries are underused but powerful. They define the maximum permissions an identity can ever receive, even if a more permissive policy is attached later. Use them to safely delegate IAM management to teams without risking privilege escalation.

5. Use Temporary Credentials for Workloads

Applications, Lambda functions, EC2 instances, and containers should never use long-term access keys embedded in code, environment variables, or config files.

Hardcoded keys accidentally pushed to a public GitHub repo is still one of the most common causes of cloud breaches.

Use IAM roles instead:

Attach a role to your EC2 instance, ECS task, Lambda function, or EKS service account
The AWS SDK automatically retrieves short-lived credentials from the instance metadata service (IMDS)
Credentials expire and rotate automatically — no manual rotation needed
Nothing to distribute, store, or accidentally commit

For on-premises or hybrid workloads, use IAM Roles Anywhere. It issues short-lived AWS credentials to on-prem servers using X.509 certificates — no long-term keys required.

For CI/CD pipelines (GitHub Actions, GitLab CI, etc.), use OIDC federation to obtain short-lived credentials scoped to only what that specific pipeline run needs.

6. Eliminate and Rotate Long-Term Credentials

If you still have IAM users with access keys, audit them now.

Use IAM Credential Reports to identify keys unused for 90+ days — deactivate and delete them
Rotate active keys on a regular schedule; use the access-keys-rotated AWS Config rule to enforce a maximum key age
Never embed access keys in source code — use AWS Secrets Manager or Parameter Store (SecureString) for runtime credentials
Set up Config or Security Hub alerts for keys older than your policy threshold

The goal is a zero-standing-credentials model: no persistent long-term keys anywhere, only short-lived credentials generated on demand.

7. Regularly Audit and Remove Unused Access

IAM drift is real. Over time, roles accumulate permissions they no longer need, users go inactive, and policies are attached "just in case." This bloat silently expands your attack surface.

Build a regular IAM hygiene process:

Use IAM Access Advisor to see the last time each service permission was used — permissions idle for 90+ days are strong candidates for removal
Review unused IAM roles using the GetServiceLastAccessedDetails API
Delete IAM users who've been replaced by federation
Replace inline policies with managed policies (they're easier to audit and reuse)
Review group memberships quarterly to reflect current team structures

Automate this with AWS Config rules, Security Hub findings, or a CSPM tool. Make it a recurring process, not a one-time cleanup.

8. Detect External and Cross-Account Access with IAM Access Analyzer

IAM Access Analyzer continuously monitors your resource-based policies — on S3 buckets, KMS keys, SQS queues, Lambda functions, IAM roles — and generates findings whenever a resource is accessible from outside your AWS account or organization.

It answers a critical question: can someone outside my account access this resource?

Enable Access Analyzer at the organization level so it catches cross-account access patterns across your entire AWS estate. A public S3 bucket or an overly permissive role trust policy can be an entry point for a supply chain compromise — and you want to know about it immediately, not in a post-incident review.

New in 2025–2026: Access Analyzer now includes unused access findings, identifying roles and policies with permissions that haven't been exercised. This combines external access detection and least-privilege auditing into a single tool.

9. Establish Permission Guardrails with SCPs and Resource Control Policies

In a multi-account AWS Organization, Service Control Policies (SCPs) define maximum permission boundaries at the account or OU level.

Think of them as a constitutional layer. Even if an admin in a member account attaches AdministratorAccess to a role, an SCP can still block them from disabling CloudTrail, creating IAM users, or operating outside approved regions.

Common SCP guardrails to implement:

Deny creation of IAM users or access keys (enforce federation org-wide)
Deny disabling of GuardDuty, CloudTrail, or Security Hub
Restrict workloads to approved AWS regions
Deny disabling S3 Block Public Access
Block root user activity in all member accounts

Resource Control Policies (RCPs), introduced in late 2024, complement SCPs by controlling resource-based policies directly. Use RCPs to build a data perimeter — ensuring only trusted identities from within your organization can access sensitive resources, regardless of what individual account policies say.

Together, SCPs and RCPs give you defense in depth at scale and help satisfy compliance frameworks like SOC 2, ISO 27001, and PCI DSS.

10. Monitor, Alert, and Respond

A strong IAM posture isn't just about configuration — it requires continuous monitoring.

AWS CloudTrail: Logs every IAM action. Enable it with log file validation and ship logs to a locked-down S3 bucket in a separate security account.
Amazon GuardDuty: Detects anomalous IAM activity — credential exfiltration, unusual API calls from unexpected geos, root credential use.
AWS Security Hub: Aggregates findings from GuardDuty, Access Analyzer, and Config into a unified dashboard with CIS AWS Foundations Benchmark scoring.
EventBridge rules: Trigger automated remediation — revoke a session, page the on-call team, isolate a role — when high-severity findings fire.

Set up dedicated alerts for: root user login, console sign-ins from new locations, disabling of security services, and creation of new admin-level roles or policies.

Summary

Practice	Priority
Use federated identity for all human access	Critical
Enforce MFA, especially on privileged accounts	Critical
Lock down and rarely use the root user	Critical
Apply least privilege and use permission boundaries	High
Use IAM roles and temporary credentials for workloads	High
Eliminate long-term access keys	High
Audit and remove unused access quarterly	High
Enable IAM Access Analyzer at org level	High
Implement SCPs and RCPs as guardrails	High
Monitor with CloudTrail, GuardDuty, and Security Hub	High

AWS IAM is powerful — but power without discipline creates risk. These practices aren't one-time checkboxes. They're habits. The teams with the strongest cloud security postures are the ones who've made IAM hygiene a continuous, automated, team-wide process rather than an afterthought.

Start with the critical items, automate what you can, and build from there.

Want to Go Deeper?

This article covers the security side of AWS IAM, but there's a lot more to master — from hands-on identity federation setup, to AWS Organizations and Directory Service, to building SSO across complex multi-account environments.

If you want to go from understanding best practices to actually implementing them, check out Learn AWS Identity Management with AWS IAM, SSO & Federation on Udemy.

The course covers AWS IAM, AWS Organizations, Directory Service, SSO, and Federation end-to-end — and it's fully updated for 2026. Whether you're preparing for an AWS certification or hardening a production environment, it's one of the most comprehensive resources available on the topic.

60+ Bash Commands for Cloud Architects & Engineers (AWS, Azure, GCP & More)

Phaustin Karani — Thu, 26 Feb 2026 14:37:00 +0000

When I first got into cloud computing some 5yrs ago, I avoided the CLI like it owed me money. I'd click around the console, doing things the slow way, telling myself the GUI was "just as good." It wasn't.

The truth is, if you're serious about working in the cloud whether you're provisioning infrastructure with Terraform, debugging a failing container at 2am, or automating deployments with Ansible you need to be comfortable in the terminal.

The CLI isn't just faster, it's often the only way.

The good news? Bash has a smaller learning curve than most programming languages. it would take you a short amount of time to become a pro in Bash than it would Python.

This guide is designed to take you from nervous about the terminal to actually preferring it.

We'll cover the essential commands grouped by category, with real-world cloud examples alongside each one.

Note: These are bash commands, native to Linux. If you're using Azure Cloud Shell in PowerShell mode, some of these won't apply directly switch to bash mode or check the Azure CLI equivalents.

Before We Start: The Golden Rules of the CLI

The CLI is case-sensitive. ls and LS are completely different. Stick to lowercase unless told otherwise.
Ctrl + C breaks any continuously running process.
Ctrl + Z suspends a process (sends it to background).
Tab auto-completes commands and file paths — use it constantly.
↑ arrow cycles through your command history.

1. Navigation & Directory Management

These are the commands you'll type hundreds of times a day.

pwd

Print Working Directory. Shows exactly where you are in the file system. Run this whenever you're disoriented.

ls

Lists the contents of the current directory. One of the most-used commands in existence.

ls -l

Long-format listing. Shows file type, permissions, owner, size, and timestamp. Essential for auditing files on a cloud VM.

ls -lt

Lists files sorted by timestamp (newest first). Useful for finding what recently changed on a server.

ls -lS

Lists files sorted by size (largest first). Great for hunting down what's eating up your disk.

ls -la

Lists all files including hidden ones (files that start with .). You'll use this constantly — things like .env, .ssh, and .bashrc are all hidden.

cd /path/to/directory

Change Directory. Use cd .. to go up one level, cd ~ to return to your home directory, and cd - to go back to the previous directory.

mkdir my-project

Make Directory. Creates a new folder. Use mkdir -p /parent/child/grandchild to create nested directories in one shot — very handy when scaffolding project structures.

rmdir empty-folder

Removes an empty directory. For non-empty directories, use rm -rf (carefully!).

2. Working with Files

cat filename.txt

Prints the entire file content to your terminal. Perfect for quick checks on config files, log snippets, or cloud-init scripts.

head -n 20 filename.log

Shows the first 20 lines of a file. Swap 20 for any number. Great for peeking at the start of large log files without loading the whole thing.

tail -n 50 filename.log

Shows the last 50 lines of a file. Indispensable for checking recent log entries.

tail -f /var/log/syslog

Follows a file in real time — new lines print as they're written. The go-to command for watching live logs on a running server.

less filename.txt

Opens a file one page at a time. Better than cat for large files. Navigation keys:

Space — next page
b — previous page
↑ / ↓ — line by line
q — quit

cp source.txt destination.txt

Copy a file. Use cp -r source-dir/ dest-dir/ to copy an entire directory recursively — useful when duplicating configuration directories.

mv oldname.txt newname.txt

Move or rename a file. Moving files between directories or renaming config files before applying changes is a daily task in cloud work.

rm filename.txt

Permanently delete a file. Use rm -rf directory/ to delete a directory and everything inside it. There's no recycle bin — double-check before running this.

touch newfile.txt

Creates an empty file, or updates the timestamp of an existing one. Often used to create placeholder files or trigger file-watching scripts.

ln -s /path/to/original linkname

Creates a symbolic link (shortcut). Useful for pointing multiple config locations to a single source of truth.

file mystery-file

Tells you what type a file is regardless of its extension. Handy when you get an undocumented artifact from a pipeline.

3. Searching & Filtering

grep "error" app.log

Searches a file and returns every line containing the string "error". One of the most powerful commands for log analysis.

grep -r "DATABASE_URL" /etc/

Recursive search through an entire directory. Use this to find where a config value is set across a server.

grep -i "warning" app.log

Case-insensitive search. Catches "Warning", "WARNING", "warning" all at once.

grep -n "timeout" nginx.conf

Returns matching lines with their line numbers. Makes it easy to jump straight to the problem in an editor.

grep -v "DEBUG" app.log

Inverts the match — returns lines that do not contain "DEBUG". Useful for filtering out noisy log entries.

find /var/log -name "*.log" -mtime -1

Find all .log files in /var/log modified in the last 1 day. The find command is incredibly powerful for locating files by name, type, size, age, or permissions.

find / -size +100M

Find all files larger than 100MB. Run this when your disk is full and you need to know why.

locate filename

Faster than find — uses a pre-built index. Update the index with sudo updatedb.

which python3

Shows the full path to an executable. Use this to confirm which version of a tool is actually being used when you have multiple installed.

4. Piping & Redirection

Piping is where bash gets truly powerful. It lets you chain commands together, feeding the output of one into the input of the next.

command1 | command2

The pipe | sends the output of command1 as input to command2.

Real-world example: Find all error lines in a log and count them:

grep "ERROR" app.log | wc -l

Another example: List running processes and filter for a specific one:

ps aux | grep nginx

command > output.txt

Redirects output to a file, overwriting it. Use >> to append instead of overwrite.

command 2> errors.txt

Redirects stderr (error output) to a file. Useful for capturing errors from scripts.

command > output.txt 2>&1

Redirects both stdout and stderr to the same file. The standard pattern for capturing all output from a cron job or automated script.

sort filename.txt | uniq -c | sort -rn

A classic pipe chain: sort lines → count unique occurrences → sort by count descending. Great for finding the most frequent entries in a log.

5. Permissions & Ownership

Understanding permissions is critical when deploying on cloud VMs or managing shared resources.

chmod 644 config.yml

Change permissions of a file. 644 means owner can read/write, group and others can only read. The classic permission for config files.

chmod 600 ~/.ssh/id_rsa

Restricts your SSH private key so only you can read it. SSH will refuse to use a key file with too-open permissions.

chmod +x deploy.sh

Makes a script executable. You'll do this every time you create a new bash script.

chown ubuntu:ubuntu /var/www/html

Change ownership of a file or directory. Specify user:group. Use chown -R to apply recursively to a whole directory.

ls -l

Review the permission string: -rwxr-xr-- breaks down as: file type, owner perms (rwx), group perms (r-x), others perms (r--).

umask 022

Sets the default permissions for newly created files. 022 means files are created as 644 and directories as 755.

6. Users, Sessions & Sudo

whoami

Prints your current username. Run this first when you SSH into an unfamiliar server to confirm who you're logged in as.

sudo command

Superuser do. Runs a command with root/admin privileges without switching users. Most system-level operations require this.

sudo su -

Switches you to the root user session entirely. Use with caution — you can do irreversible damage as root.

su - otheruser

Switch user to another account, loading their environment. Use exit to return to your original session.

passwd

Change your password. Admins can change any user's password with passwd username.

id

Shows your user ID (UID), group ID (GID), and all group memberships. Useful for debugging permission issues.

last

Shows the login history for all users. Use this to audit who has been accessing a server.

Shows who is currently logged in and what they're doing. A quick security check.

7. Process Management

ps aux

Lists all running processes on the system with detailed info including user, CPU%, memory%, and command.

ps aux | grep nginx

Find a specific process by name. The standard way to check if a service is running.

top

Real-time, interactive process viewer. Shows CPU and memory usage live. Press q to quit, k to kill a process by PID.

htop

A better, more visual version of top. Install it with sudo apt-get install htop.

kill 1234

Send a termination signal to process with PID 1234. Get the PID from ps aux.

kill -9 1234

Force kill a process — non-ignorable. Use this when a regular kill doesn't work.

pkill nginx

Kill processes by name instead of PID. More convenient when you know the service name.

nohup ./script.sh &

Runs a script in the background and keeps it running even after you log out. The & puts it in the background, nohup prevents it from dying when your session ends.

jobs

Lists background jobs running in the current session.

bg %1

Resume a suspended job in the background. Use fg %1 to bring it back to the foreground.

8. Networking & Connectivity

ping google.com

Tests basic network connectivity and measures latency. The first thing to run when troubleshooting connectivity on a cloud VM.

curl -I https://example.com

Fetches just the HTTP headers from a URL. Use this to check if a web service is responding and what status code it returns.

curl -X POST https://api.example.com/endpoint \
  -H "Content-Type: application/json" \
  -d '{"key": "value"}'

Make an HTTP POST request with JSON data. Essential for testing APIs and webhooks directly from the command line.

wget https://example.com/file.tar.gz

Downloads a file from the internet. Unlike curl, wget saves to disk by default and supports resuming interrupted downloads.

netstat -tuln

Shows all open ports and listening services. Use this to confirm your app is bound to the right port after deployment.

ss -tuln

The modern replacement for netstat. Faster and more detailed.

traceroute google.com

Traces the network path to a destination, showing every hop. Invaluable for diagnosing where a network issue is occurring.

nslookup myapp.example.com

DNS lookup — resolves a hostname to an IP. Use this to verify DNS propagation after updating records.

dig myapp.example.com

More detailed DNS lookup than nslookup. Shows TTLs, record types, and the responding nameserver.

ifconfig

Shows network interface configuration (IP addresses, etc.). On newer systems, use ip addr instead.

ip addr

The modern way to view network interfaces and IP addresses.

9. SSH & Key Management

SSH is how you access virtually every cloud VM. Know these commands cold.

ssh ubuntu@203.0.113.10

Connect to a remote server. Replace ubuntu with your username and the IP with your instance's public IP.

ssh -i ~/.ssh/mykey.pem ubuntu@203.0.113.10

Connect using a specific private key file — required for AWS EC2 instances and others that use key-pair authentication.

ssh-keygen -t ed25519 -C "your_email@example.com"

Generate a new SSH key pair. ed25519 is the modern, recommended algorithm. Your public key goes on the server; your private key stays on your machine.

cat ~/.ssh/id_ed25519.pub

View your public key so you can copy it to a server's authorized_keys or paste it into a cloud provider's console.

ssh-copy-id ubuntu@203.0.113.10

Copies your public key to a remote server's authorized keys automatically. Much easier than doing it manually.

scp file.txt ubuntu@203.0.113.10:/home/ubuntu/

Securely copy a file to a remote server over SSH. Use scp -r for directories.

ssh -L 8080:localhost:80 ubuntu@203.0.113.10

SSH tunneling / port forwarding. Forwards your local port 8080 to port 80 on the remote server. Incredibly useful for accessing services that aren't publicly exposed (databases, internal dashboards).

10. Package Management (apt)

For Debian/Ubuntu-based systems — the most common Linux distros you'll encounter on AWS, GCP, and Azure.

sudo apt-get update

Refreshes the package list from repositories. Always run this before installing anything. It doesn't install or upgrade anything — it just updates the metadata.

sudo apt-get upgrade

Upgrades all installed packages to their latest versions. Run update first.

sudo apt-get install nginx

Installs a package by name. You'll use this constantly when provisioning new servers.

sudo apt-get remove nginx

Removes a package but leaves its config files in place.

sudo apt-get purge nginx

Removes a package and its config files. Use this for a clean uninstall.

sudo apt-get autoremove

Removes packages that were installed as dependencies but are no longer needed. Good for keeping VMs lean.

apt-cache search keyword

Search available packages by keyword without installing anything.

11. System Monitoring & Disk

df -h

Shows disk usage of all mounted filesystems in human-readable format (GB, MB). The first thing to check when you get a "disk full" alert.

du -sh /var/log/

Shows the total size of a specific directory. Use du -sh * inside a directory to see sizes of all subdirectories at once.

free -h

Shows memory usage (total, used, free, cached) in human-readable format.

uptime

Shows how long the system has been running and the load average over 1, 5, and 15 minutes. A quick health check.

uname -a

Prints system information: kernel version, architecture, OS. Useful when you're not sure exactly what you're running on.

lsblk

Lists all block devices (disks and partitions). Use this after attaching a new EBS volume (AWS) or persistent disk (GCP) to see it appear.

mount /dev/sdb1 /mnt/data

Mounts a disk partition to a directory. You'll do this after attaching and formatting new cloud storage volumes.

12. Text Processing & Editing

echo "Hello, World!"

Prints text to the terminal. Use with redirection to write to files: echo "export PATH=$PATH:/usr/local/bin" >> ~/.bashrc

nano filename.txt

A simple, beginner-friendly text editor. Use Ctrl+O to save, Ctrl+X to exit. Good for quick edits on remote servers.

vim filename.txt

A powerful but steep-learning-curve editor. i to enter insert mode, Esc then :wq to save and quit. Worth learning the basics.

sed -i 's/old-value/new-value/g' config.txt

Stream editor — find and replace text in a file without opening an editor. The -i flag edits in-place. Extremely useful in deployment scripts.

awk '{print $1, $3}' data.txt

A powerful text-processing tool. This example prints the 1st and 3rd columns. Great for parsing log files and extracting specific fields.

wc -l filename.txt

Word count — counts lines, words, or characters. wc -l counts lines. Use it to count log entries: grep "ERROR" app.log | wc -l

sort filename.txt

Sorts lines alphabetically. Use sort -n for numerical sort, sort -r for reverse.

uniq -c sorted.txt

Counts duplicate adjacent lines — always pair with sort first. Classic pattern for frequency analysis.

cut -d',' -f1,3 data.csv

Extracts specific columns from delimited files. Perfect for parsing CSV exports from cloud billing or logs.

13. Environment & Shell

env

Lists all environment variables currently set. Use this to verify that your secrets and config values loaded correctly.

export MY_VAR="hello"

Sets an environment variable for the current session and any child processes. Use this for passing config to scripts.

echo $MY_VAR

Prints the value of an environment variable.

source ~/.bashrc

Reloads your shell config file. Run this after editing .bashrc or .bash_profile so changes take effect without logging out.

history

Shows your command history. Use history | grep ssh to find a previously used SSH command.

!42

Re-runs command number 42 from your history. Use !! to repeat the last command (common pattern: sudo !! to re-run the last command with sudo).

alias ll='ls -la'

Creates a shortcut for a command. Add your aliases to ~/.bashrc to make them permanent.

crontab -e

Opens the cron job editor to schedule recurring tasks. This is how you automate backups, cleanup scripts, and health checks on cloud VMs.

shutdown -h +10

Shuts down the system in 10 minutes. Use shutdown -r now to reboot immediately. Always requires root/sudo.

Cloud Provider Quick Reference

All major cloud providers offer a browser-based Cloud Shell that drops you straight into a bash environment — no SSH setup required.

Provider	Cloud Shell Access	CLI Tool
AWS	CloudShell in Console	`aws` CLI
Google Cloud	Cloud Shell button (top nav)	`gcloud` CLI
Azure	Cloud Shell icon (top nav)	`az` CLI (bash or PowerShell)
Oracle Cloud	Cloud Shell in Console	`oci` CLI
IBM Cloud	Cloud Shell button	`ibmcloud` CLI

Handy Cloud CLI Examples

AWS — List all S3 buckets:

aws s3 ls

AWS — Copy a file to S3:

aws s3 cp myfile.txt s3://my-bucket/

GCP — List Compute Engine instances:

gcloud compute instances list

GCP — SSH into an instance:

gcloud compute ssh my-instance --zone=us-central1-a

Azure — List resource groups:

az group list --output table

Azure — Show VM status:

az vm show -g MyResourceGroup -n MyVM --show-details

Putting It All Together: A Real Workflow

Here's what a typical cloud debugging session might look like using the commands above:

# 1. SSH into your instance
ssh -i ~/.ssh/prod-key.pem ubuntu@203.0.113.10

# 2. Check who you are and system status
whoami
uptime
free -h
df -h

# 3. Find what's eating disk space
du -sh /var/log/*

# 4. Check if your app process is running
ps aux | grep myapp

# 5. Watch live logs
tail -f /var/log/myapp/app.log

# 6. Count errors in the last hour's log
grep "ERROR" /var/log/myapp/app.log | wc -l

# 7. Check which ports are listening
ss -tuln

# 8. Restart a service if needed
sudo systemctl restart myapp

Final Thoughts

The CLI felt intimidating to me at first too. Now I reach for it before the console almost every time it's faster, scriptable, and forces you to actually understand what's happening on your infrastructure rather than clicking through abstractions.

Start with the navigation and file commands until they're muscle memory. Then move to grep, pipes, and permissions. Once those click, the rest follows naturally.

The best way to get comfortable? Stop avoiding the CLI and use it for everything even when the GUI would be faster at first. The short-term friction pays off fast.

If there are specific command categories you'd like me to expand on, drop a comment below.

I gave OpenClaw its own computer and a Telegram Bot. Here's What Happened

Phaustin Karani — Fri, 13 Feb 2026 14:53:55 +0000

Quick thing before we get into it: if you're thinking about running OpenClaw yourself, skip putting it on your home or work machine for security reasons, of course. Get a cheap VPS.

I used AWS because I work in the cloud daily and know how to keep costs in check, but for most people, especially if you've never managed cloud infrastructure before, AWS bills can sneak up on you fast. That's why I'd point non-cloud users straight to Hostinger Open Claw VPS.

Their VPS plans are simple, predictably priced, and you won't wake up to a surprise bill because you forgot to set a budget alert.

Okay. Now the story.

What OpenClaw Actually Is (Because Most People Get This Wrong)

It's not a chatbot. It's not a SaaS dashboard. It's not another wrapper around GPT with a monthly subscription slapped on it.

OpenClaw is an open-source personal AI assistant that runs on your own machine or server, connects to whichever AI model you choose, and talks to you through whatever chat app you already use.

Telegram, WhatsApp, Discord, iMessage, Slack. You message it like a contact. It does things.

Because it runs on your infrastructure and not someone else's servers, your data stays yours.

You pick the model from a list of various top models like DeepSeek Claude, GPT-5.2, or local models if you want. You control what it can access. And since it's fully open source, you can extend it however you need to.

OpenClaw was built by Peter Steinberger and a growing community of contributors. It's only a few months old and moves fast — new capabilities show up regularly.

My Setup

Ubuntu 24.04 VPS on AWS Lightsail costs $12/per month. Mistral, as the AI backbone, routed through a Vercel API gateway I set up as an abstraction layer, makes it easier to swap models later without touching every config file. Telegram for delivery.

I configured it to send me a structured morning report at 7:00 AM East Africa Time every day. For the last week, it has worked exactly as intended. Getting there, though, was a different story.

The First Thing I Got Wrong: Claude Opus 4.6 Ate My Credits

When I first installed OpenClaw, I defaulted to Claude Opus 4.6 as the model. Makes sense in theory, best output, most capable, why not start with the best?

My credit balance had other opinions.

Opus 4.6 is an incredible model. It's also priced like one. For a daily scheduled task firing the same structured request every morning, using Opus is like going swimming in the local pool with full scuba diving equipment.

What is the output quality difference compared to a cheaper model on this kind of repetitive, well-defined task? Honestly negligible. The price difference? Not negligible at all.

I switched to Mistral after the first few hours and haven't looked back. The reports are just as useful. The bill is much easier to live with.

Lesson: match the model to the task. Opus-level models are worth it for complex, nuanced, one-off reasoning. For structured daily reports pulling from consistent data, use something cheaper and cache what you can.

On Caching: Seriously, Do This

If you're running OpenClaw for repetitive scheduled tasks, look into caching your API calls.

Any part of your prompt that doesn't change between runs, system instructions, static context, or your data schema doesn't need to be re-sent and re-processed every single time.

Most major AI APIs support prompt caching in some form, and the cost savings on high-frequency tasks are real.

The general principle:

❌ Expensive model + no caching + daily repetitive task = you will regret it
✅ Cheaper model + cached static context + well-structured prompt = same job, fraction of the cost

Why I'm on AWS But Suggesting Hostinger for Most People

I work in the cloud professionally. Setting up billing alerts, IAM permissions, configuring CloudWatch dashboards, monitoring resource usage, and watching for cost anomalies is just part of how I operate every day. So AWS Lightsail made sense for me.

I knew how to keep it under control.

I’ve watched people with no cloud background spin up resources, forget they even exist, and then get blindsided by a massive bill weeks later.

A quick scroll through the Google Cloud subreddit is all it takes. The horror stories from mismanaged infrastructure are a reminder that in the cloud, what you forget can cost you

AWS is powerful precisely because it has so many knobs to turn, and if you don't know which ones matter, that flexibility becomes a liability.

For anyone who doesn't live in cloud infrastructure, I'd genuinely recommend starting with Hostinger's Openclaw VPS plans.

Clean Ubuntu setup, predictable flat-rate pricing, no need to understand reserved instances, Route 53 or any of the things that make AWS bills confusing. You get a server, it costs what it says it costs, you SSH in and get to work.

A basic 2 GB RAM instance is more than enough for what OpenClaw needs, but Hostinger is even more generous and gives you an 8GB RAM 2vCPU and 8TB bandwidth at $7.99/mon

If you are already familiar with AWS or GCP, use what you're comfortable with.

If you don't, don't learn cloud infrastructure and OpenClaw at the same time. That's just unnecessary pain.

Days 1 and 2: The Part Nobody Writes About

Every write-up about a new tool skips straight to "and then it worked great." So let me be the one to actually tell you what the first 48 hours looked like.

The cron job that was definitely running (it wasn't)

My plan: schedule the morning report with a cron job. Simple. Except nothing happened. No error. No log. No indication that anything had been attempted. Just silence.

Turned out to be three things piling on each other simultaneously:

Environment variables set in my normal shell session weren't available to the cron environment
The virtual environment path wasn't being activated correctly inside the cron command
I'd set the schedule for 7 AM without accounting for the server running UTC, not EAT. I needed 04:00 UTC, not 07:00

None of these is hard to fix once you know what's wrong. Finding all three without clear error messages at 11 PM was a different experience.

Always add logging to your cron jobs from day one. Redirect output to a file. Silent failures are the worst kind.
your-command >> /home/user/openclaw/cron.log 2>&1

Manual requests: educational, but a grind

While the cron issue was unresolved, I was testing by firing requests manually from the terminal. Run the command. Watch the output. Tweak something. Run again.

It works as a debugging method. As a workflow, it's a bumper, especially when you're used to just typing in Telegram and having things happen.

The upside: by the time the scheduler was working, I understood every layer of the system. The manual phase taught me OpenClaw better than any documentation would have.

Day 3, 7:02 AM

Telegram notification. Report there. Automated. No manual intervention.

The relief was disproportionate to the actual achievement, but completely understandable given the previous 48 hours. It's been delivering every morning since.

What Else People Are Doing With This Thing

My scheduled report is a pretty narrow use case. Looking at what the broader community has built:

Email triage and sending, calendar management — all from a WhatsApp or Telegram message
Remote coding sessions via Claude Code or OpenAI Codex — kick off a task from your phone, get results in chat
Image generation through Nano Banana — request visuals in chat, receive them without switching apps
Browser control for automated form filling, flight check-ins, and data extraction from sites without APIs
Health and biometric tracking — WHOOP, Oura, and other wearables connected and queryable in chat
Obsidian and personal knowledge base integration — builds your second brain from conversations
Smart home control — lights, air purifiers, environmental conditions managed against defined goals
Custom audio content — one person had it write meditation scripts, convert to TTS, add ambient sound, and deliver the finished file

Check out open claw subreddits for ideas of tasks you can automate with openclaw

The pattern across all of these is the same: friction that used to require opening multiple apps gets compressed into one message in a chat thread you already have open.

That's the value proposition, and once you feel it working, it's hard to go back.

Honestly? I'm Kind of Hooked.

I didn't expect to feel this way about infrastructure software. But there's something genuinely satisfying about a system that works while you're not working, the report arrives before I've opened a browser, before the noise of the day starts.

Information I specifically configured to matter to me, already processed, already waiting.

And the thing about OpenClaw is that you start building around it almost immediately. Within a few days, I was already thinking about the next automation, the next friction point that a scheduled task could eliminate.

That's a different relationship than most software creates.

What's coming next for my setup

I'm adding the Gemini API alongside Mistral, specifically Gemini Nano for lightweight, fast tasks that don't need heavy models. Paired with Nano Banana for image generation, I can start building visual content workflows directly from Telegram without switching tools.

The one I'm most excited about: OpenAI API with Codex access. Triggering remote coding sessions from my phone, having OpenClaw run code, fix tests, open PRs, and report back while I'm doing something else is exactly the kind of async workflow this thing is built for. Community members are already doing this, and the demos I see on Discord are wild.

Beyond specific APIs: a broader daily automation layer. Not just one morning report, but a set of scheduled and on-demand tasks that handle the routine stuff, email triage, content summarisation, task reminders with context, all through Telegram. Fewer context switches, not more tools.

Should You Try This?

If you're comfortable with a terminal and patient enough to debug environment issues, yes. The first two days will test you. Day three makes it worth it.

A few things that'll save you time:

Don't start with the most expensive model. Mistral Devstral or Qwen3 is fine for most scheduled tasks. Move up when you actually need to.
Cache your static prompt content from the start. Your system instructions aren't changing between runs — don't pay to send them every time.
Match model to task complexity. Daily structured reports don't need Opus or GPT 5.3. Complex one-off reasoning might. Know the difference.
Add logging to cron jobs immediately. Future you will be grateful.
Set UTC times for everything server-side. Convert locally.

If you want to run this without cloud billing anxiety, Hostinger's VPS plans are the low-drama option —flat pricing, Ubuntu setup in under 20 minutes, no surprise bills. Once the server is live, everything else follows from the OpenClaw docs.

Set aside two to three days for initial setup. Give yourself permission to find the first 48 hours frustrating.

Day three is worth it.

Backing Up GitHub Repositories to Amazon S3 (What Nobody Warns You About)

Phaustin Karani — Tue, 13 Jan 2026 14:05:49 +0000

I didn’t start backing up my GitHub repositories because I distrusted GitHub.

I started because I realized something uncomfortable: GitHub had become a single point of failure for work I actually cared about.

Between long-lived projects, experiments I might want years later, and repositories that quietly became important, I didn’t like the idea that a deleted repo, a locked account, or a bad force-push could wipe everything out.

I wanted an off-platform, boring, automated backup.

Amazon S3 fit that mental model perfectly:

Independent of GitHub
Cheap
Extremely durable
Built for long-term storage

What sounded simple turned out to be very easy to get wrong.
This article documents the approach that finally worked — including the mistakes.

What this article covers

This guide shows how to:

Back up multiple GitHub repositories
Run backups weekly
Preserve full Git history (branches + tags)
Avoid AWS access keys
Use OIDC + temporary credentials
Store backups safely in Amazon S3

This is not a ZIP download tutorial.
This is a real backup.

High-level architecture (correct model)

Architecture flow

GitHub Actions runs on a schedule
GitHub issues an OIDC identity token
AWS STS validates the token
AWS issues temporary credentials
The workflow uploads backups to S3

No IAM users.
No static secrets.
Nothing long-lived.

Why `git bundle` (and not ZIP files)

ZIP files look tempting until you need to restore.

ZIP backups:

❌ Lose commit history
❌ Drop branches and tags
❌ Are painful to restore correctly

A git bundle is different. It contains:

All commits
All branches
All tags
In a single portable file

Creating a bundle

git bundle create repo-backup.bundle --all

If your backup can’t restore history, it’s not a backup.

The IAM problem that caused most of the pain

The hardest part wasn’t GitHub Actions.
It was AWS permissions.

The confusing part

AWS uses two different policy types:

Policy type	Used for	Requires `Principal`
IAM role policy	Identity permissions	❌ No
S3 bucket policy	Resource permissions	✅ Yes

They look similar.
They behave very differently.

Why “invalid principal” kept appearing

At one point, everything looked correct but AWS kept returning:

Invalid principal

The reason:

An IAM policy was pasted into an S3 bucket policy
Or the principal ARN didn’t match the actual role

The rule that finally made it click

IAM role policies never define a Principal
S3 bucket policies must define who is allowed access

S3 authorization model (the missing mental model)

This diagram explains the core issue that caused most confusion.

Key idea

An S3 upload succeeds only if BOTH are true:

The IAM role policy allows the action
The S3 bucket policy allows the same role

If either side denies it → AccessDenied

The GitHub Actions workflow (clean and boring)

Once the security model was clear, the workflow itself became simple.

name: Weekly S3 Repo Backup

on:
  schedule:
    - cron: "15 3 * * 0"   # Weekly
  workflow_dispatch: {}

permissions:
  id-token: write
  contents: read

jobs:
  backup:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout full history
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Create git bundle
        run: |
          set -e
          REPO_NAME="${GITHUB_REPOSITORY#*/}"
          TS="$(date -u +%Y-%m-%dT%H-%M-%SZ)"
          mkdir -p backups
          git bundle create "backups/${REPO_NAME}-${TS}.bundle" --all
          sha256sum "backups/${REPO_NAME}-${TS}.bundle" > "backups/${REPO_NAME}-${TS}.sha256"

      - name: Configure AWS credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: <IAM_ROLE_ARN>
          aws-region: <AWS_REGION>

      - name: Upload to S3
        run: |
          aws s3 cp backups/ \
            s3://<bucket-name>/github-backups/${GITHUB_REPOSITORY}/ \
            --recursive

Nothing clever.
Nothing hidden.
That’s intentional.

Terraform setup (AWS side)

This is a minimal Terraform configuration — no extras.

GitHub OIDC provider

resource "aws_iam_openid_connect_provider" "github" {
  url = "https://token.actions.githubusercontent.com"

  client_id_list = [
    "sts.amazonaws.com"
  ]

  thumbprint_list = [
    "6938fd4d98bab03faadb97b34396831e3780aea1"
  ]
}

IAM role for GitHub Actions

resource "aws_iam_role" "github_backup" {
  name = "github-actions-s3-backup"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Action = "sts:AssumeRoleWithWebIdentity"
      Principal = {
        Federated = aws_iam_openid_connect_provider.github.arn
      }
      Condition = {
        StringLike = {
          "token.actions.githubusercontent.com:sub" = "repo:*/*:*"
        }
      }
    }]
  })
}

IAM role policy (write-only S3 access)

resource "aws_iam_role_policy" "s3_backup" {
  role = aws_iam_role.github_backup.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = ["s3:ListBucket"]
        Resource = "arn:aws:s3:::example-backup-bucket"
      },
      {
        Effect = "Allow"
        Action = [
          "s3:PutObject",
          "s3:AbortMultipartUpload"
        ]
        Resource = "arn:aws:s3:::example-backup-bucket/*"
      }
    ]
  })
}

Restoring from a backup

Restoring is refreshingly simple.

git clone repo-backup.bundle restored-repo
cd restored-repo
git push --all origin
git push --tags origin

No GitHub API.
No special tooling.
Just Git.

Lessons learned

Sketch trust relationships before writing policies
Don’t trust AWS error messages blindly
Never use root as a bucket principal
Test with one repo before scaling
Keep backups boring

Final thoughts

This setup isn’t flashy and that’s the point.

A good backup system is something you forget about until the day you need it.
And when that day comes, it should just work.

I built an actual companion right in your IDE.

Phaustin Karani — Thu, 08 Jan 2026 05:09:47 +0000

I Built a Spy for My Python Code: It Was Secretly Calling AWS 40x More Than I Thought

Phaustin Karani ・ Jan 4

#python #programming #vscode #cursor

Best solution to vibecoded sites

Phaustin Karani — Sun, 04 Jan 2026 16:19:54 +0000

The Best Web Hosting for Vibecoded Sites: Speed Without the Headache

Phaustin Karani ・ Nov 21 '25

#vibecoding #webdev #nextjs #ai

[Boost]

Phaustin Karani — Sun, 04 Jan 2026 16:18:33 +0000

What Your AWS and GCP Python Code Is Really Doing (I Built a VS Code Extension to Find Out)

Phaustin Karani ・ Jan 4

#python #programming #vscode #cursor

I Built a Spy for My Python Code: It Was Secretly Calling AWS 40x More Than I Thought

Phaustin Karani — Sun, 04 Jan 2026 12:32:42 +0000

TL;DR: Python Code Mentor is the only VS Code extension that provides AI-powered explanations for AWS, Google Cloud, and multi-cloud Python code patterns. It goes beyond syntax highlighting to explain how serverless architectures actually behave in the real world.

The Problem with Current Code Analysis Tools

Most VS Code extensions are good at helping you write Python. Some go a step further and focus on a single cloud provider. But almost none of them explain what your cloud code is actually doing — or why it’s structured the way it is.

So you end up context-switching constantly:

Googling “how does Lambda work with S3”
Comparing Cloud Functions vs Lambda
Jumping between docs, Google AI Overviews, or ChatGPT just to understand why a Firestore query is slow

Instead of understanding the code in front of you, you’re stitching together mental models from AI summaries and documentation tabs.

That gap is what pushed me to build Python Code Mentor.

What Makes Python Code Mentor Different

1. Multi-Cloud Intelligence

This extension understands AWS and Google Cloud in the same codebase — something I couldn’t find in existing tools.

It automatically detects:

AWS patterns: Lambda handlers, boto3 calls, S3 and DynamoDB interactions
GCP patterns: Cloud Functions, Google Cloud SDK usage, Firestore and BigQuery operations
Mixed environments: Codebases that touch both clouds (very common in real-world systems)

When you select code, the extension knows whether you’re dealing with AWS Lambda or Google Cloud Functions and explains it in the right context.

No generic answers. No cloud-agnostic fluff.

2. Serverless Function Tracing

Most tools stop at syntax. This one focuses on execution.

AWS Lambda Example:

def lambda_handler(event, context):
    s3_client = boto3.client('s3')
    # Select this code, hit Ctrl+Shift+W

Instead of a shallow explanation, the extension generates realistic S3 trigger events and walks through the function step-by-step:

how the event is structured,
how boto3 calls are executed,
what gets returned to AWS.

Google Cloud Functions Example:

@functions_framework.http
def process_request(request):
    db = firestore.Client()
    # Select this code, hit Ctrl+Alt+F

Here, it simulates real HTTP requests and explains how Cloud Functions handle them — including cold starts, Firestore access, and response handling.

This is the kind of clarity you usually only get after deploying and debugging in production.

3. Cloud SDK Deep Dives

Instead of stopping at method signatures, Python Code Mentor explains what each cloud operation means in practice:

Cost implications: “This DynamoDB scan will cost $X per million items”
Performance impact: “This Firestore query isn’t indexed and will be slow”
Security considerations: “This S3 operation requires these IAM permissions”
Best practices: “Batch writes would be more efficient here”

It connects the dots between code, architecture, and real-world consequences.

4. Architecture Pattern Recognition

The extension recognizes and explains common cloud patterns:

Event-driven flows: S3 → Lambda → DynamoDB
Pub/Sub messaging: Cloud Functions triggered by Pub/Sub
Data pipelines: BigQuery → Cloud Functions → Cloud Storage
Multi-cloud sync: Moving data between AWS and GCP

Instead of guessing “what kind of system is this?”, the tool tells you.

Unique Features No Other Extension Has

Smart Context Switching

# AWS code
s3_client = boto3.client('s3')
dynamodb = boto3.resource('dynamodb')

# GCP code in same file
storage_client = storage.Client()
db = firestore.Client()

Select the AWS section → AWS-specific explanations
Select the GCP section → GCP-specific explanations
Select both → a comparative breakdown of how the two clouds differ

This alone removes a ton of mental overhead.

Multi-Cloud Comparative Analysis

When both cloud patterns are detected, the extension provides insights like:

Why a team might use both S3 and Cloud Storage
How Lambda and Cloud Functions pricing models affect architecture
How DynamoDB and Firestore differ in transaction handling

It explains the why, not just the how.

Realistic Event Generation

Instead of toy examples, the extension generates events that closely match real deployments:

API Gateway events for HTTP Lambdas
S3 events for storage-triggered functions
Pub/Sub messages for message-driven Cloud Functions
Firestore triggers for database-driven logic

This makes tracing feel practical, not theoretical.

Cost and Performance Insights

Cloud mistakes are expensive. The extension helps surface them early:

Flags costly operations before deployment
Suggests optimizations based on real cloud behavior
Explains scaling implications of specific code paths

What Didn’t Work (and Took Way Longer Than Expected)

This part matters, because building this wasn’t smooth sailing.

Gemini API Was the Biggest Challenge

Integrating the Gemini API turned out to be far more complex than expected.

What I hoped would take a couple of days ended up taking nearly two full weeks.

Some of the issues:

Inconsistent response formats depending on prompt complexity
Rate limiting behaving differently than documented
Edge cases where responses were technically correct but unusable for code explanations
Multiple prompt iterations just to make explanations cloud-aware, not generic

A lot of time went into retry logic, fallbacks, and prompt tuning just to make the output reliable inside an editor.

Classic Developer Pain Points

Some other very common (and frustrating) issues:

VS Code API quirks: Things that work in one version silently fail in another
Command conflicts: Keybindings clashing with popular extensions
Performance tradeoffs: Making sure AI calls didn’t freeze the editor
Messy real-world code: Half-written functions, commented blocks, mixed styles
Expectation gaps: Users expect magic, but AI still needs guardrails

None of this is glamorous — but it’s the reality of building developer tools.

Technical Implementation

Built with Kiro IDE

Python Code Mentor was built using Kiro IDE, Amazon’s AI-powered development environment.

Kiro’s understanding of AWS patterns significantly accelerated development, especially for:

Rapid prototyping of cloud integrations
Automated testing of AWS service interactions
AI-powered code reviews
Generating documentation for complex workflows

For cloud-native tooling, it felt like the IDE was speaking the same language as the problem.

Pattern Detection Engine

// Automatically detects patterns like:
- /lambda_handler|event|context/ (AWS Lambda)
- /@functions_framework|functions_framework/ (GCP Cloud Functions)
- /boto3|aws_|s3|dynamodb/ (AWS SDK)
- /from google\.cloud|google\.cloud/ (Google Cloud SDK)

Intelligent Routing

Detected code is routed to the correct analysis engine:

AWS-only → AWS-specific explanations
GCP-only → GCP-specific explanations
Mixed → Multi-cloud comparisons
Plain Python → Standard explanations

AI-Powered Explanations

Uses Google’s Gemini AI with cloud-aware prompts that understand:

Serverless execution models
Cloud service interactions
Pricing tradeoffs
Security best practices
Performance characteristics

Commands and Shortcuts

Core Python Features

Ctrl+Shift+E – Explain Python code
Ctrl+Shift+T – Trace execution
Ctrl+Shift+L – Analyze logic
Ctrl+Shift+Q – Generate quizzes

AWS Features

Ctrl+Shift+A – Explain AWS/Lambda code
Ctrl+Shift+W – Trace Lambda execution
Ctrl+Shift+B – boto3 deep dive

GCP Features

Ctrl+Alt+G – Explain GCP code
Ctrl+Alt+F – Trace Cloud Functions
Ctrl+Alt+S – Google Cloud SDK deep dive

Real-World Use Cases

Learning Cloud Patterns

Dropped into an unfamiliar serverless app? Select a function and understand the full event flow.

Multi-Cloud Migrations

Moving between AWS and GCP? Get side-by-side explanations of equivalent patterns.

Code Reviews

Quickly understand what cloud interactions do — and whether they follow best practices.

Debugging Production Issues

Trace realistic events to understand how failures propagate through your code.

Why This Matters for Modern Development

Multi-cloud is normal: Most teams use more than one provider
Serverless is everywhere: Event-driven code needs event-aware tools
Cloud costs are real: Understanding behavior saves money
The learning curve is steep: This tool focuses on the why, not just the what

Installation and Setup

Python Code Mentor is available on both major extension registries:

VS Code Marketplace
https://marketplace.visualstudio.com/items?itemName=karaniph.python-code-mentor
Open VSX (Cursor,Windsurf,Google antigravity VSCodium, etc.)
https://open-vsx.org/extension/karaniph/python-code-mentor

Setup:

Install the extension
Get a free Google Gemini API key
Add the key in VS Code settings
Start selecting cloud code

No cloud credentials required.

The Bottom Line

Python Code Mentor is built for people who actually run Python in the cloud.

It:

Understands AWS and Google Cloud patterns
Traces real serverless execution
Explains cost and performance tradeoffs
Handles multi-cloud codebases intelligently
Teaches architecture, not just syntax

If you write cloud-based Python, this extension turns your editor into a learning tool — not just a text box.

Availability: VS Code Marketplace & Open VSX
Requirements: VS Code 1.85.0+, Google Gemini API key (free)
Pricing: Freemium — 20 free requests/day, unlimited with PRO license

Best Web Hosting 2026: I Tested 11 Providers (Real Performance Data)

Phaustin Karani — Thu, 18 Dec 2025 09:16:59 +0000

So you're shopping for web hosting. Maybe you're launching your first side project, migrating an existing site, or just tired of your current host's sluggish performance. The problem? Every "best hosting" article reads like it was written by someone who's never actually deployed a real site.

I spent the last three months testing 11 different hosting providers. Real websites. Real performance monitoring. Real money spent. Here's what I found.

Why This Actually Matters (Especially for Devs)

Your hosting choice affects more than just uptime. It impacts:

Page load times → which affects Core Web Vitals → which affects SEO ranking
TTFB (Time to First Byte) → baseline for all subsequent performance metrics
Developer experience → SSH access, Git integration, staging environments
Infrastructure flexibility → scaling options when your side project actually takes off

A bad host can tank your search rankings no matter how solid your code is. Google's algorithm prioritizes fast, reliable sites. Your server is the foundation.

My Testing Methodology

I deployed test WordPress sites on each platform and monitored:

Uptime (60+ days using UptimeRobot)
Load times (GTmetrix, WebPageTest, multiple global locations)
Support quality (submitted tickets, timed responses, evaluated expertise)
Real-world performance under simulated traffic spikes

I'm not affiliated with any of these companies. Just sharing what worked and what didn't.

The Hosts, Ranked by Use Case

1. Hostinger — Best Bang for Your Buck

$2.99/month | Check it out →

The Real Talk: Hostinger consistently outperformed hosts costing 3x more. LiteSpeed servers + NVMe SSDs delivered load times around 0.8 seconds. For context, that's faster than many managed WordPress hosts.

What Stood Out:

Custom hPanel control panel (actually better than cPanel for beginners)
AI website builder that doesn't suck
Free domain, SSL, weekly backups included
99.9% uptime over my testing period

The Catches:

Live chat queues during peak hours (10-15 minute waits)
Renewal prices jump (always read the fine print)
Some advanced features locked behind higher tiers

Who Should Use It: First-time site owners, small businesses, developers on a budget, anyone running WordPress

My Test Results:

Average load time: 0.82s
Uptime: 99.91%
TTFB: 210ms

2. HostGator — Solid for Complete Beginners

$2.29/month | Check it out →

The Real Talk: HostGator is that reliable friend who's been around forever. Nothing fancy, but it gets the job done. Setup literally took me 12 minutes from signup to live WordPress site.

What Stood Out:

cPanel (industry standard, no learning curve)
One-click WordPress install
24/7 phone support (rare these days)
45-day money-back guarantee (longer than most)

The Catches:

Servers only in the U.S. (Texas/Utah)
Entry plans use traditional HDDs, not SSDs
Renewal prices triple (seriously)
Basic security features cost extra

Who Should Use It: Complete beginners, bloggers, small business owners who want simplicity

My Test Results:

Average load time: 1.9s
Uptime: 99.6%
TTFB: 480ms

Not the fastest, but consistent and reliable.

3. Bluehost — The WordPress Training Wheels

$2.95/month | Check it out →

The Real Talk: Officially recommended by WordPress.org since 2005. If you've never touched WordPress before, this is your best bet. The WordPress Academy alone justifies the price.

What Stood Out:

WordPress Academy with free courses
Guided setup wizard (hand-holding in the best way)
$200 in marketing credits included
99.98% uptime in my tests

The Catches:

Domain privacy costs extra
Support quality varies wildly
Advanced security features paywalled

Who Should Use It: WordPress newcomers, bloggers learning the platform, anyone who wants extensive documentation

My Test Results:

Average load time: 1.2s
Uptime: 99.98%
TTFB: 350ms

4. Kinsta — When Performance Actually Matters

$35/month | Check it out →

The Real Talk: This is premium hosting that actually earns the premium price. Built on Google Cloud's C2 compute-optimized VMs. If your site generates revenue, this is worth every penny.

What Stood Out:

Sub-500ms response times from multiple continents
35+ data centers globally
Auto-scaling (handled a traffic spike to 50k visitors without blinking)
Expert WordPress support that actually knows their stuff

The Catches:

WordPress only (no static sites, no other CMS)
No email hosting
$35/month minimum (overkill for hobby projects)

Who Should Use It: High-traffic WordPress sites, e-commerce stores, agencies, anyone making money from their site

My Test Results:

Average load time: 0.48s
Uptime: 99.99%
TTFB: 140ms

The fastest I tested. Not close.

5. Cloudways — Managed Cloud Without the Headaches

$11/month | Check it out →

The Real Talk: You get to choose your cloud provider (DigitalOcean, AWS, Google Cloud, Linode) but Cloudways handles all the sysadmin stuff. Best of both worlds.

What Stood Out:

Choose your own infrastructure
Built-in Redis/Varnish caching
Pay-as-you-go scaling
Staging environments with one click

The Catches:

Learning curve for complete beginners
No domain registration
Add-on costs can accumulate fast

Who Should Use It: Growing businesses, developers who want cloud power without cloud complexity, agencies managing multiple sites

My Test Results (DigitalOcean + NYC datacenter):

Average load time: 0.91s
Uptime: 99.94%
TTFB: 190ms

6. Liquid Web — Zero-Downtime Guarantee (Actually)

$5.25/month | Check it out →

The Real Talk: 100% uptime guarantee backed by compensation. In 90 days of monitoring, I had zero downtime events. Support averaged 59-second response times.

What Stood Out:

Actually reliable uptime
U.S.-based support that knows their stuff
Free migrations with zero downtime
10Gbps network connections

The Catches:

No shared hosting (VPS minimum)
Premium pricing reflects premium service
Some features require technical knowledge

Who Should Use It: E-commerce businesses, high-traffic sites, anyone where downtime = lost revenue

7. WP Engine — Managed WordPress at Scale

$20/month | Check it out →

The Real Talk: Built specifically for WordPress. Automatic updates, daily backups, staging environments, Git integration. If you're serious about WordPress development, this is your tooling.

What Stood Out:

Developer-friendly (SSH, WP-CLI, Git)
Staging environments on all plans
Automatic WordPress core/plugin updates
Used by major brands for a reason

The Catches:

WordPress only
Higher starting price
No email hosting

Who Should Use It: WordPress developers, content-heavy sites, digital agencies, growing businesses

8. A2 Hosting — Turbo Plans Are Legit Fast

$2.99/month | Check it out →

The Real Talk: The Turbo plans delivered load times under 0.3 seconds in North America. That's not marketing BS—I verified it repeatedly.

What Stood Out:

Turbo plans = ridiculous speed
Developer tools on all plans (SSH, Git)
Anytime money-back guarantee (pro-rated)
SSD storage across all tiers

The Catches:

Need Turbo plan for Turbo speed (basic plans are meh)
Interface feels cluttered
Checkout upsells are aggressive

Who Should Use It: Performance-focused sites, developers who need SSH access, WordPress sites prioritizing speed

9. DreamHost — Privacy-First Hosting

$2.95/month | Check it out →

The Real Talk: 100% uptime guarantee (not 99.9%, but 100%). They credit your account for any downtime. Also, they don't sell your data, which is rare in 2026.

What Stood Out:

100% uptime guarantee with compensation
Free domain privacy (others charge $10-15/year)
97-day money-back guarantee
Open-source commitment

The Catches:

Custom control panel (not cPanel)
Phone support limited to U.S. hours
Less marketing polish than competitors

Who Should Use It: Privacy-conscious users, nonprofits, bloggers, anyone valuing ethical hosting

10. Namecheap — Cheapest Entry Point

$1.58/month | Check it out →

The Real Talk: It's cheap. That's the selling point. If you need to test an idea or launch a simple site on an absolute shoestring budget, this works.

What Stood Out:

Extremely affordable
Standard cPanel
Free domain + SSL
Solid domain management tools

The Catches:

Limited resources on budget plans
Not suitable for traffic growth
Support can be slow
Basic features compared to others

Who Should Use It: First websites, testing projects, personal portfolios, hobby sites

11. Contabo — Budget VPS Powerhouse

$4.15/month | Check it out →

The Real Talk: 400GB SSD storage for $4.15/month. That's insane value. But this is unmanaged VPS—you need to know what you're doing.

What Stood Out:

Massive resource allocation for the price
9 data centers globally
No renewal price increases
Snapshot/backup functionality

The Catches:

Unmanaged (no hand-holding)
Limited support hours
No control panel on basic plans
Not beginner-friendly at all

Who Should Use It: Developers, tech-savvy users, resource-heavy applications, anyone comfortable with Linux

Quick Comparison Table

Host	Best For	Starting $	Speed Rating	Dev Tools
Hostinger	Value	$2.99	⚡⚡⚡⚡	Good
HostGator	Beginners	$2.29	⚡⚡	Basic
Bluehost	WP Learning	$2.95	⚡⚡⚡	Basic
Kinsta	Performance	$35	⚡⚡⚡⚡⚡	Excellent
Cloudways	Flexibility	$11	⚡⚡⚡⚡	Excellent
Liquid Web	Reliability	$5.25	⚡⚡⚡⚡	Good
WP Engine	WP Scale	$20	⚡⚡⚡⚡	Excellent
A2 Hosting	Speed	$2.99	⚡⚡⚡⚡	Good
DreamHost	Privacy	$2.95	⚡⚡⚡	Good
Namecheap	Budget	$1.58	⚡⚡	Basic
Contabo	VPS Value	$4.15	⚡⚡⚡	Advanced

Common Mistakes I've Seen

Choosing by Price Alone

Cheapest host = overcrowded servers, outdated hardware, terrible support. A slow site costs you more in lost traffic than a few extra bucks per month.

Ignoring Renewal Prices

That $2/month promo rate? Often jumps to $12+ on renewal. Calculate your 3-year cost, not just year one.

Wrong Server Location

Audience in Europe, server in California? Those milliseconds add up. Choose data centers near your users or use a CDN.

Not Testing Backups

"Daily backups included" doesn't mean "easily accessible backups." Test the restore process before you desperately need it.

Believing "Unlimited"

"Unlimited bandwidth" always has limits buried in the TOS. Most hosts will throttle or suspend high-usage accounts.

How to Actually Choose

Starting Your First Site?

→ HostGator or Bluehost

Both offer intuitive setup and extensive documentation. HostGator's slightly cheaper; Bluehost has better WordPress resources.

Running E-Commerce?

→ Kinsta, Liquid Web, or WP Engine

You need guaranteed uptime and fast load times. Downtime = lost sales. The premium price is insurance.

High-Traffic or Scaling Up?

→ Cloudways, Kinsta, or Liquid Web

You need infrastructure that scales seamlessly. Cloudways offers max flexibility, Kinsta offers best WordPress performance, Liquid Web offers zero-downtime reliability.

Developer/Tech User?

→ Cloudways, A2 Hosting, or Contabo

You want SSH, Git, and configuration freedom. Cloudways provides managed cloud flexibility, A2 offers dev tools at shared hosting prices, Contabo gives raw VPS power.

Tight Budget?

→ Hostinger or Namecheap

Both deliver legitimate hosting under $5/month. Hostinger has better performance; Namecheap has lower entry pricing.

The Technical Stuff That Matters

Core Web Vitals

Your server's response time is the foundation for LCP, CLS, and INP. A slow server guarantees poor Core Web Vitals scores, which Google uses for ranking.

TTFB (Time to First Byte)

Premium hosts deliver TTFB under 200ms. Budget hosts often exceed 500ms. This difference compounds through every page element.

Uptime & Crawl Budget

Frequent downtime reduces Google's crawl frequency, which delays indexing of new content. For news sites or frequently updated content, this directly impacts visibility.

Server Location & CDN

Physical distance creates latency. For local businesses, server location matters. For global reach, use a CDN to distribute content to edge locations worldwide.

My Actual Recommendations

If you're just starting out: Go with Hostinger. Best value, solid performance, beginner-friendly.

If you're building with WordPress: Try Bluehost (learning) or Kinsta (performance).

If downtime costs you money: Choose Liquid Web. The uptime guarantee is real.

If you want cloud power without complexity: Use Cloudways.

If you're obsessed with speed: Check out A2 Hosting (Turbo) or Kinsta.

If you're on a shoestring budget: Start with Namecheap or Hostinger.

If you need VPS resources affordably: Go with Contabo (if you're technical).

The difference between a $3/month host and a $30/month host isn't always 10x better performance—but it's often the difference between a site that loads in 0.8 seconds versus 2.5 seconds. In 2026, that matters for both user experience and search rankings.

FAQ

Can I switch hosts without hurting SEO?

Yes, if done correctly. Most premium hosts offer free migrations. Key is maintaining uptime during the switch and ensuring all URLs stay the same. A proper migration can actually improve SEO if you're moving to faster infrastructure.

Do I really need managed hosting?

Depends on your technical skills and time. Managed hosting (where the host handles updates, security, optimizations) is worth it if you'd rather focus on building than maintaining servers.

What's the actual difference between shared, VPS, and cloud?

Shared: Your site shares a server with many others. Cheapest but can be slower.
VPS: Virtual Private Server gives you dedicated resources. More consistent performance.
Cloud: Your site runs across multiple servers. Most scalable and reliable, but requires more technical knowledge.

Is expensive hosting always better?

No. The right fit matters more. A $2/month host can serve a personal blog fine. A $200/month dedicated server might be essential for high-traffic e-commerce. Match hosting to your needs.

How important is 24/7 support?

Very, if you're not technical. Sites can break at 3 AM on Sunday. Every hour of downtime costs you traffic and sales.

Tested these hosts myself. Not sponsored. Just sharing what actually worked.

vibe coders gather here a solution for your hosting needs.

Phaustin Karani — Tue, 09 Dec 2025 13:32:20 +0000

The Best Web Hosting for Vibecoded Sites: Speed Without the Headache

Phaustin Karani ・ Nov 21

#vibecoding #webdev #nextjs #ai

vibe coders gather here

Phaustin Karani — Tue, 09 Dec 2025 13:31:21 +0000

The Best Web Hosting for Vibecoded Sites: Speed Without the Headache

Phaustin Karani ・ Nov 21

#vibecoding #webdev #nextjs #ai

The Best Web Hosting for Vibecoded Sites: Speed Without the Headache

Phaustin Karani — Fri, 21 Nov 2025 12:55:24 +0000

You have built a vibecoded site in Lovable, Cursor, or Bolt and need a home for it? We tested the top hosts to find which ones handle AI-generated code best. Here’s the truth.

After spending countless hours vibecoding and blowing through your credits, you prompted a masterpiece in Lovable, generated a full-stack UI in v0, or built a functional prototype in Bolt.

The code is clean, modern, and ready to ship. But now you face the "deployment gap."

Most hosting advice is stuck in 2019. They talk about "databases" and "installations." But vibecoded sites are different. They are often modern React apps, Next.js artifacts, or clean HTML/JS exports that need a different kind of engine.

You don't need a legacy dashboard; you need a place that understands git push and modern build pipelines.

After testing deploy-ability (how easy it is to get code from your AI tool to a live URL) and raw speed, here are the platforms that actually understand the assignment.

The Verdict: Top Hosts for AI & Low-Code Builds

Hostinger Horizons is the clear winner for the sheer "AI-native" experience. Lovable deserves a special spot for being the ultimate all-in-one builder.

Kinsta is our top pick for developers deploying heavy backend apps.

Best Hosting for AI-Generated Sites

Rank	Host	Best For	Price	The "Vibe" Check	Link
1	Hostinger	AI-Native Building (Horizons)	~$6.99/mo	The new Horizons platform is built for vibecoding.	Check Hostinger Deals
2	Lovable	Prompt-to-Publish (All-in-One)	Free / $25/mo	Build AND host in the same chat window.	Try Lovable
3	Kinsta	Application Hosting (PaaS)	~$7/mo (Apps)	Deploys Docker/Node.js apps directly from GitHub.	Visit Kinsta
4	Cloudways	Full-Stack Cloud Power	~$14/mo	Best for heavy AI backends (Python/Django) on AWS.	Start Cloudways Trial
5	Vercel	Frontend Apps (Next.js, React)	Free / Pro $20/mo	The standard for modern, edge-deployed UI/UX.	Visit Vercel
6	Liquid Web	Enterprise VPS & Compute	~$16/mo	Dedicated power for apps running heavy logic.	View Liquid Web

The Vibecoded Hosting Deep Dive (Reviews)

1. Hostinger: The AI-Native Powerhouse (Horizons)
Best For: The pure "Vibecoding" workflow, where the tool writes the code for you.

Hostinger isn't just hosting anymore; they have launched Hostinger Horizons, a platform specifically designed for the low-code/no-code generation.

If you are using their AI tools to generate sites, Horizons handles the infrastructure invisibly. Even for standard hosting, their Git integration is surprisingly robust.

Ease of Use: 5/5 (Horizons is chat-based; hPanel is intuitive)
Pricing: Starts at ~$6.99/mo (1-year term).

✅ Pros:

Horizons Platform: You can prompt a site into existence and it’s hosted instantly.
Git Integration: Pushing updates from a repo is seamless even on cheap plans.
Value: Unbeatable price for the speed (LiteSpeed servers).

❌ Cons:

Support: Chat-only support can sometimes be slow during peak hours.
Backend Limits: Harder to run complex custom server environments (like specific Python versions) compared to Kinsta.

Get the Hostinger Discount Here

2. Lovable: The All-in-One Vibe Builder

Best For: Rapid prototyping and launching without ever leaving the AI chat.

Lovable is taking the vibecoding world by storm. It’s not just a host; it’s a full-stack builder.

You describe your app ("Make a SaaS dashboard"), and it writes the code and hosts it on a lovable.app domain instantly. It’s the friction-free dream.

Ease of Use: 6/5 (Literally just typing English)
Pricing: Free (limited daily credits), Pro starts at $25/mo.

✅ Pros:

Instant Publish: No "deployment" phase; you click one button and it's live.
Supabase Integration: Handles databases automatically (users, auth, data) without you touching SQL.
GitHub Sync: Exports clean code to GitHub if you want to move to Kinsta/Netlify later.

❌ Cons:

Cost: The Pro plan ($25/mo) is pricier than basic hosting if you stop building.
Lock-in Risk: While you can export, the "magic" happens inside their ecosystem.

Try Lovable

3. Kinsta: The Application Hosting Platform

Best For: React, Next.js, Node.js, and Dockerized AI Apps.
Forget what you know about Kinsta being "just for blogs." Their Application Hosting platform is a beast for modern code.

If your vibecoded app has a package.json file or a Dockerfile, Kinsta is arguably the best place to put it. It runs on Google Cloud’s Premium Tier.

Ease of Use: 4.5/5 (Developer-focused but beautiful UI)
Pricing: Pay-as-you-go, roughly ~$7/mo for small apps.

✅ Pros:

Auto-Deploy: Connects to GitHub; builds and deploys automatically on push.
free tier: Kinsta have a very generous free tier where you can deploy apps for free as you test the platform.
Performance: Google Cloud Premium Tier means unmatched speed.
Buildpacks: Auto-detects Node, Python, Go, etc., without needing complex config.

❌ Cons:

Usage Pricing: Costs can scale up if your traffic spikes or your app is resource-heavy.
No Email: Does not include email hosting (you need Google Workspace/Outlook).

Get started with Kinsta App Hosting

4. Cloudways: The Backend Beast

Best For: Full-stack AI apps (Python, Django, Laravel) requiring Cloud Compute.
Cloudways gives you a managed server on AWS, DigitalOcean, or Google Cloud.

This is crucial if you need full control over the server environment (e.g., installing specific Python libraries for an AI agent) but still want a friendly UI to manage it.

Ease of Use: 3/5 (Requires understanding concepts like "Servers" vs "Apps")
Pricing: Starts at ~$14/mo (DigitalOcean droplet).

✅ Pros:

Flexibility: Choose your cloud provider (AWS, Google, DO).
Scalability: One-click vertical scaling (add more RAM/CPU instantly).
Price/Performance: You get raw cloud power without the managed markup of other premium hosts.

❌ Cons:

Complexity: Not for total beginners; you need to know a little about what a "server" is.
No Domain Registration: You must buy domains elsewhere (like Namecheap) and point them here.

Deploy on Cloudways

5. Vercel: The Frontend Hosting Standard

Best For: Next.js, React, and any modern framework that requires Edge deployment.

If your "vibecoded" site is a Single Page Application (SPA) built with React, Vue, or the gold standard, Next.js, you need Vercel.

Vercel specializes in hosting modern frontend applications on its fast, global Edge Network.

This means your site loads instantly anywhere in the world. It’s the platform favored by top tech companies and most Next.js developers.

Ease of Use: 5/5 (Connect Git repo, done)

Pricing: Free (Hobby tier) / Pro starts at $20/mo.

✅ Pros:

Edge Functions: Run small snippets of backend code globally for blazing-fast APIs.
Instant Deployment: Connects directly to GitHub/GitLab; deploys automatically on every push.
Previews: Automatically creates a unique URL for every pull request for easy team review.

❌ Cons:

Complexity: Requires knowledge of modern Git workflows.
Serverless Cost: Enterprise-level scaling can be expensive if you run very heavy Edge Functions.

Deploy Your Frontend on Vercel

6. Liquid Web: The Scalable VPS

Best For: Heavy AI applications and High-Traffic projects.
If your vibecoded project is a SaaS tool that processes data or handles thousands of concurrent users, shared hosting will crash.

Liquid Web offers managed VPS (Virtual Private Servers) with dedicated RAM and CPU.

Ease of Use: 2/5 (Geared towards power users/businesses)
Pricing: Starts at ~$16/mo for VPS.

✅ Pros:

Power: Dedicated resources mean your app won't slow down because of other users.
Support: Legendary 24/7 support (Heroic Support®) that answers instantly.
Control: Root access to your server to install anything you want.

❌ Cons:

Overkill: Too expensive and complex for a simple portfolio or landing page.
UI: The interface is functional/industrial, not "modern" or "vibey."

Check Liquid Web VPS

For The Pros: What About Netlify & AWS Amplify?

If you are comfortable with command-line tools or connecting repos directly, Netlify and AWS Amplify are industry standards.

My Personal Experience: The AI Password Generator
I personally used Lovable to build an AI-powered password generator.

The process was seamless—I described the logic ("create a secure AI enabled password generator that uses a memorable phrase but adds complexity"), and Lovable built the UI and logic in seconds.

However, for the final hosting, I wanted it to live on my own custom infrastructure.

Netlify: I connected the Lovable-exported GitHub repo to Netlify. It automatically detected the build settings.

Now, every time I ask Lovable to "tweak the color scheme" and sync to GitHub, Netlify rebuilds the site in about 20 seconds.

AWS Amplify: I also tested this on Amplify. It was overkill for a password generator, but the integration with AWS Cognito (for user login) was incredible.

The Pros & Cons of this Route:
Netlify

Pros: Best "Drag-and-Drop" deployment for static folders; amazing free tier.
Cons: Backend functions (serverless) have execution limits on the free tier.

AWS Amplify

Pros: Infinite scalability; deep integration with AWS AI services.
Cons: its an overkill for small sites it cost me over $67/month to host 2 apps.

Final Thoughts: Deployment is the New Coding
In the era of vibecoding, "deployment" is just the final step of prompting.

Want to prompt and publish in one place? Use Lovable.
Have a repo and want value? Use Hostinger Horizons.
Building a heavy app? Use Kinsta or Cloudways.

Stop keeping your code in a repo. Ship it.

Forem: Phaustin Karani

AWS IAM Security Best Practices in 2026: A Complete Guide

1. Use Federated Identity for Human Access

2. Enforce Multi-Factor Authentication (MFA)

3. Protect and Restrict the Root User

4. Apply the Principle of Least Privilege

5. Use Temporary Credentials for Workloads

6. Eliminate and Rotate Long-Term Credentials

7. Regularly Audit and Remove Unused Access

8. Detect External and Cross-Account Access with IAM Access Analyzer

9. Establish Permission Guardrails with SCPs and Resource Control Policies

10. Monitor, Alert, and Respond

Summary

Want to Go Deeper?

60+ Bash Commands for Cloud Architects & Engineers (AWS, Azure, GCP & More)

Before We Start: The Golden Rules of the CLI

1. Navigation & Directory Management

2. Working with Files

3. Searching & Filtering

4. Piping & Redirection

5. Permissions & Ownership

6. Users, Sessions & Sudo

7. Process Management

8. Networking & Connectivity

9. SSH & Key Management

10. Package Management (apt)

11. System Monitoring & Disk

12. Text Processing & Editing

13. Environment & Shell

Cloud Provider Quick Reference

Handy Cloud CLI Examples

Putting It All Together: A Real Workflow

Final Thoughts

I gave OpenClaw its own computer and a Telegram Bot. Here's What Happened

What OpenClaw Actually Is (Because Most People Get This Wrong)

My Setup

The First Thing I Got Wrong: Claude Opus 4.6 Ate My Credits

On Caching: Seriously, Do This

Why I'm on AWS But Suggesting Hostinger for Most People

Days 1 and 2: The Part Nobody Writes About

The cron job that was definitely running (it wasn't)

Manual requests: educational, but a grind

Day 3, 7:02 AM

What Else People Are Doing With This Thing

Honestly? I'm Kind of Hooked.

What's coming next for my setup

Should You Try This?

Backing Up GitHub Repositories to Amazon S3 (What Nobody Warns You About)

What this article covers

High-level architecture (correct model)

Architecture flow

Why git bundle (and not ZIP files)

Creating a bundle

The IAM problem that caused most of the pain

The confusing part

Why “invalid principal” kept appearing

The rule that finally made it click

S3 authorization model (the missing mental model)

Key idea

The GitHub Actions workflow (clean and boring)

Terraform setup (AWS side)

GitHub OIDC provider

IAM role for GitHub Actions

IAM role policy (write-only S3 access)

Restoring from a backup

Lessons learned

Final thoughts

I built an actual companion right in your IDE.

I Built a Spy for My Python Code: It Was Secretly Calling AWS 40x More Than I Thought

Phaustin Karani ・ Jan 4

Best solution to vibecoded sites

The Best Web Hosting for Vibecoded Sites: Speed Without the Headache

Phaustin Karani ・ Nov 21 '25

[Boost]

What Your AWS and GCP Python Code Is Really Doing (I Built a VS Code Extension to Find Out)

Phaustin Karani ・ Jan 4

I Built a Spy for My Python Code: It Was Secretly Calling AWS 40x More Than I Thought

The Problem with Current Code Analysis Tools

What Makes Python Code Mentor Different

1. Multi-Cloud Intelligence

Why `git bundle` (and not ZIP files)