DevOps Beginner

AutoSys Installation: The 5 Checks Before You Deploy

Q: What is AUTOSERV in AutoSys?

AUTOSERV is an environment variable that identifies the AutoSys instance name. It's used by all AutoSys commands to know which database instance to connect to. If you have DEV, QAT, and PRD instances, each will have a different AUTOSERV value. **Critical safety issue**: There is no safety prompt. If AUTOSERV is wrong, you'll run commands against the wrong environment. Always verify with `autoflags -a` before destructive operations.

Q: What port does AutoSys use?

The default port for AutoSys agent communication is 7520. This port must be open in firewalls between the AutoSys Event Processor (server) and every agent machine. If the port is blocked, agents show as INACTIVE and jobs stay PENDING forever. The WCC web interface uses port 8080 (or 8443 for HTTPS) by default.

Q: How do I check if AutoSys is running?

Two commands: - `chk_auto_up -A` checks Event Processor status (RUNNING/STOPPED) - `autoflags -a` checks overall system status including Event Server connection Both commands are available from the command line on the AutoSys server after sourcing the AutoSys environment variables.

Q: Can AutoSys run on Linux?

Yes. AutoSys fully supports RHEL and CentOS Linux for both the server and agent components. It also supports Windows Server, AIX, and Solaris for agent machines. The Event Processor and Event Server typically run on Linux in production environments.

Q: How many AutoSys instances can run on one server?

Multiple instances can run on the same physical or virtual server. Each instance has its own AUTOSERV identifier and its own database (Event Server). This is commonly used to have separate DEV, QAT, and PRD AutoSys environments on the same hardware. **Safety requirement**: Use separate OS service accounts for each instance (autosys_dev, autosys_prd). Shared accounts inevitably lead to 'oops, wrong instance' incidents.

Q: What's the first thing I should do after SSH'ing into an AutoSys server?

Run `autoflags -a` and verify AUTOSERV. This tells you exactly which instance you're connected to. Then check `chk_auto_up -A` to confirm the Event Processor is running. This 5-second check prevents the most common mistake: thinking you're in DEV when you're actually in PRD. Put AUTOSERV in your prompt so you never forget.

📅 March 19, 2026 ⏱ 3 min read 🎯 Beginner

Where developers are forged. · Structured learning · Free forever.

📍 Part of: AutoSys → Topic 4 of 30

Port 7520 must be open.

🧑‍💻 Beginner-friendly — no prior DevOps experience needed

In this tutorial, you'll learn

Port 7520 must be open.

AUTOSERV is the most important environment variable — wrong value = wrong instance. No error. No warning.
Put AUTOSERV in your shell prompt. Always visible. Never forgotten.
Port 7520 must be open between Event Processor and every agent. Closed port = jobs stay PENDING.

thecodeforge.io

AutoSys Installation Flow

Autosys Installation Setup

✦ Plain-English analogy ✦ Real code with output ✦ Interview questions

⚡Quick Answer

AUTOSERV is the instance identifier — everything depends on it. Wrong AUTOSERV = wrong database = wrong jobs.
Port 7520 must be open between Event Processor and every agent. Closed port = jobs stay PENDING forever.
8GB RAM minimum for small installs, 16GB+ for production. Underprovisioning causes event processor lag.
AUTOUSER ($AUTOUSER/out/event_demon.$AUTOSERV) is your first stop for debugging. Logs tell you everything.
Post-install test: chk_auto_up -A (processor running), autoflags -a (server reachable), test job end-to-end.
Silent killer: no dedicated service account. Mixing AutoSys with application accounts = permission hell.

AssumptionThe engineer assumed their shell environment inherited the correct AUTOSERV from system defaults. It didn't. It inherited from a stale profile that set AUTOSERV=PRD from a previous session.

Root causeAUTOSERV is not set automatically. It must be explicitly set in your shell profile or manually before running commands. The engineer's .bash_profile had AUTOSERV=PRD. They logged in, sourced it, and started working on 'DEV' — but AUTOSERV was still PRD. All AutoSys commands read AUTOSERV. No command warns you which instance you're connected to. There's no 'are you sure you want to delete jobs in PRODUCTION?' prompt.

Fix1. Always display AUTOSERV in your prompt: export PS1='\u@\h:\$AUTOSERV \w\$ ' 2. Make the first line of every automation script check and echo AUTOSERV 3. Use separate service accounts for each environment (autosys_dev, autosys_prd) — no shared accounts 4. After installation, run autoflags -a first thing. It shows the instance name. Verify before any destructive JIL operation.

Key Lesson

AUTOSERV determines your instance. There's no safety net.Always verify autoflags -a before running JIL deletions or updates.Put AUTOSERV in your command prompt. Always visible, never forgotten.Separate OS accounts for DEV, QAT, PRD — the cheapest insurance.

Production Debug Guide

The 5 things to check when a fresh install doesn't behave

chk_auto_up -A returns 'Event Processor not running'→Check event_demon log: tail -100 $AUTOUSER/out/event_demon.$AUTOSERV. Look for database connection errors or lock file conflicts. Start processor: eventor

autoflags -a works, but jobs never run (stay PENDING/RUNNING forever)→Check agent communication: autoping -M %. If agents show INACTIVE, port 7520 may be blocked. Verify firewall between AutoSys server and agent machines.

autorep shows no jobs even though JIL inserts succeeded→Check AUTOSERV environment variable. You're probably connected to a different instance (e.g., inserted into DEV, checking in PRD).

sendevent commands work on some jobs but not others→Check if jobs are on HOLD or ICE. autorep -J JOB -q. Also verify AUTOSERV matches the instance where jobs were defined.

Your infrastructure team handles the AutoSys install. You just use it. That's the theory.

Reality: you'll SSH into the AutoSys server at 2 AM to debug why a job isn't running. And if you don't know where the logs live or which AUTOSERV you're in, you'll waste 30 minutes figuring out the basics.

This guide assumes the install is done. We focus on the 5 checks that verify it's working — and the environment variables you'll type every single day.

Prerequisites before installation

Before AutoSys can be installed, you need:

On the AutoSys server: - A supported OS (RHEL/CentOS Linux, or Windows Server) - A supported database (historically Sybase ASE, now Oracle or other RDBMS) - Java runtime (AutoSys WCC runs on Tomcat) - Sufficient RAM — at least 8GB for a small installation, 16GB+ for production - A dedicated service account (commonly named autosys or appuser)

On each agent machine: - A supported OS (Linux, Windows, AIX, Solaris) - The AutoSys Agent package (lightweight, minimal footprint) - Network connectivity to the AutoSys server on the configured port

Port planning matters. The Event Processor communicates with agents over specific ports (default 7520). Make sure firewalls are open between the AutoSys server and every agent machine.

The silent killer: Using a shared account for multiple environments. If the same OS account connects to DEV and PRD, you will eventually run a command against the wrong instance.

pre_install_checks.sh · BASH

123456789101112131415161718

# Check Java version (required for WCC)
java -version

# Check available memory
free -h

# Check disk space on AutoSys installation paths
df -h /opt/CA /opt/autosys /u01

# Verify network connectivity to agent machines
autoping -m agent-machine-01

# Check AutoSys port is open between server and agent
nc -zv agent-machine-01 7520

# Verify separate service accounts (critical)
whoami
# Should be autosys_dev, autosys_qat, or autosys_prd — never 'autosys' shared

▶ Output

openjdk version "11.0.21" 2023-10-17
Total: 31Gi Used: 8.2Gi Free: 23Gi

Filesystem Size Used Avail Use%
/opt/CA 50G 12G 38G 24%

Connection to agent-machine-01 7520 port [tcp] succeeded!

Current user: autosys_dev

Mental Model

The Restaurant Model

Walk into the wrong restaurant (wrong AUTOSERV) and you'll serve the wrong customers.

Event Server = kitchen inventory system (database)
Event Processor = head chef (reads orders, dispatches cooks)
Remote Agent = wait station (each room has one)
AUTOSERV = restaurant name — orders don't cross between restaurants
Port 7520 = the pathway between kitchen and wait stations

📊 Production Insight

A team provisioned a new AutoSys server with 4GB RAM. The install completed. chk_auto_up showed RUNNING. Then they loaded 500 jobs. The Event Processor started logging memory errors. Jobs queued but didn't start. Condition evaluations took 30 seconds.

Root cause: The Event Processor caches job definitions and event history. With 500 jobs, memory usage exceeded 4GB. The OS started swapping. Performance collapsed.

Fix: Increased to 16GB. No more issues.

Diagnosis: Check event_demon log for 'OutOfMemoryError' or 'cannot allocate memory'. Autorep -q on large jobs should complete in <1 second.

Rule: 8GB minimum for small installs (<100 jobs). 16GB+ for production. RAM is cheap. Underprovisioning causes outages.

🎯 Key Takeaway

8GB RAM minimum, 16GB+ for production. Underprovisioning kills performance.

Port 7520 open between server and all agents. Closed port = pending jobs permanently.

Dedicated service account per environment. Shared accounts cause cross-instance mistakes.

Verify all prerequisites BEFORE calling Broadcom support.

Pre-install decision guide

IfFewer than 100 jobs, non-critical

→

Use8GB RAM, single server, no HA. Simple and cheap.

If100-500 jobs, production critical

→

Use16GB RAM, dedicated database server, agent redundancy.

If500+ jobs or financial/regulated workloads

→

Use32GB+ RAM, dual Event Server HA, load-balanced agents.

IfMultiple environments (DEV/QAT/PRD)

→

UseSeparate OS service accounts per environment. No shared accounts.

Key environment variables you'll use every day

AutoSys uses several environment variables that control which instance you're talking to and where log files live. These are set in your shell profile (.bash_profile or .profile) for the AutoSys service account.

Knowing these by heart makes you much faster at debugging. When something goes wrong at 3 AM and you're SSH'd into the AutoSys server, these are the first things you check.

Most critical: AUTOSERV. It tells AutoSys which instance to connect to. Set it wrong, and you'll submit jobs to the wrong environment. No warning. No error. Just silent wrongness.

The 3 AM trick: If a job isn't behaving, echo $AUTOSERV and autoflags -a. If they don't match your expectation, fix the environment before touching anything else.

autosys_env.sh · BASH

1234567891011121314151617181920212223

# The AutoSys instance name — critical, everything uses this
export AUTOSERV=ACE

# AutoSys installation directory
export AUTOSYS=/opt/CA/WorkloadAutomationAE

# AutoSys user/data directory (logs, config files, PID files)
export AUTOUSER=/opt/CA/WorkloadAutomationAE/autouser

# Path to AutoSys binaries (needed for jil, autorep, sendevent etc.)
export PATH=$AUTOSYS/bin:$PATH

# The "3 AM sanity check": put AUTOSERV in your prompt
export PS1='[\u@\h:$AUTOSERV \W]\$ '

# Add the above to your .bash_profile for the autosys service account:
# source this file or add these lines to ~/.bash_profile

# Verify the environment is set correctly:
echo "Instance: $AUTOSERV"
echo "Install dir: $AUTOSYS"
echo "User dir: $AUTOUSER"
autoflags -a

▶ Output

[autosys@server:ACE ~]$
Instance: ACE
Install dir: /opt/CA/WorkloadAutomationAE
User dir: /opt/CA/WorkloadAutomationAE/autouser

AutoSys r12.0 Build 213 — Event Processor: RUNNING

⚠ Multiple AutoSys instances on one server

Large enterprises sometimes run multiple AutoSys instances on the same server — for example, DEV, QAT, and PRD. Each instance has its own AUTOSERV value. When switching between instances, always verify your AUTOSERV variable first or you'll accidentally submit jobs to the wrong environment. Put AUTOSERV in your prompt. You'll never be confused again.

📊 Production Insight

A senior engineer spent 45 minutes debugging why a job wasn't running. They checked logs, verified the agent, restarted the Event Processor. Nothing worked.

The problem: AUTOSERV was set to DEV. They were looking at the PRD instance. The job was in DEV, not PRD. The entire investigation was against the wrong database.

Fix: The team added autoflags -a to the beginning of every runbook. First command, every time.

Diagnosis: autoflags -a shows the instance name and connection status. Always run it before assuming where you are.

Rule: First command after SSH: autoflags -a. Check AUTOSERV. Every. Single. Time.

🎯 Key Takeaway

AUTOSERV determines which instance you're connected to. Wrong AUTOSERV = wrong database.

Put AUTOSERV in your shell prompt: export PS1='[$AUTOSERV] \u@\h\$ '

$AUTOUSER/out/event_demon.$AUTOSERV — logs include instance name. Always grep for it.

First command after SSH: autoflags -a. Verify before any destructive operation.

Verifying a fresh installation

After installation, run through this checklist before declaring the system ready:

Event Processor is running — chk_auto_up -A
Can connect to Event Server — autoflags -a
Agents are registered and active — autorep -M %
Can define a test job — create a simple JIL job
WCC web interface is reachable — open the browser URL
Test job runs successfully end-to-end

Test job best practice: Use a job that does something harmless but observable. Write to a test log file. Run it manually first on the agent machine to verify the command works. Then let AutoSys run it.

The rookie mistake: Assuming the test job works because the JIL insert succeeded. A successful insert only means the syntax was correct. It doesn't mean the command will run successfully on the agent.

verify_install.sh · BASH

123456789101112131415161718192021222324252627282930313233

# 1. Check Event Processor
chk_auto_up -A

# 2. Check overall system
autoflags -a

# 3. List all registered machines
autorep -M %

# 4. Insert and immediately force-run a test job
jil << 'JIL'
insert_job: INSTALL_TEST
job_type: CMD
command: echo 'AutoSys installation verified successfully' >> /tmp/autosys_test.log
machine: autosys-server
owner: autosys
date_conditions: 0
JIL

# Force start it
sendevent -E FORCE_STARTJOB -J INSTALL_TEST

# Wait a few seconds, then check its status
autorep -J INSTALL_TEST

# Check the test log
cat /tmp/autosys_test.log

# Verify the test job runs on the correct machine
# The machine attribute must match the agent hostname

# Clean up
echo 'delete_job: INSTALL_TEST' | jil

▶ Output

Event Processor: RUNNING

MACHINE NAME STATUS MAX LOAD
autosys-server ACTIVE 100
agent-machine-01 ACTIVE 100
agent-machine-02 ACTIVE 100

Job Name Last Start Status
INSTALL_TEST 03/19/2026 14:22:01 SU

/tmp/autosys_test.log:
AutoSys installation verified successfully

💡The test job proves the full stack

A test job that runs 'echo' on the local server proves: Event Processor is running, job definition is stored, agent communication works, job execution works, output is written. That's everything you need for a basic install verification.

📊 Production Insight

A team proudly declared their AutoSys install 'verified' after chk_auto_up passed. A week later, their first real job stayed PENDING. No logs. No errors.

The problem: The test job ran on the local server (autosys-server). The real job needed to run on a remote agent. No one had tested remote agent connectivity.

The agent machine had a firewall blocking port 7520. The test never caught it.

Fix: Run the test job on each agent machine, not just the server.

Diagnosis: autoping -m remote-agent shows active/inactive. If inactive, test port: telnet remote-agent 7520.

Rule: Verify connectivity to EVERY agent machine before declaring the install complete. One test job on the server proves nothing about remote agents.

🎯 Key Takeaway

chk_auto_up -A confirms processor is running.

autoflags -a confirms Event Server connectivity.

autorep -M % shows all registered agents — check each one.

Test job on the server proves local execution. Test job on each agent proves remote.

Clean up test jobs after verification — delete_job leaves no trace.

🗂 AutoSys Environment Variables — At a Glance

Set these in your shell profile. Know them by heart.

Environment Variable	What it controls	Example value	What breaks if wrong
AUTOSERV	AutoSys instance name (connects to correct database)	ACE, PRD, DEV	Wrong instance → wrong jobs. No error. Silent failure.
AUTOSYS	Installation directory path	/opt/CA/WorkloadAutomationAE	Commands fail with 'command not found'
AUTOUSER	User data and log directory	/opt/CA/WorkloadAutomationAE/autouser	Logs go to wrong place; event_demon can't write
PATH	Must include AutoSys bin directory	$AUTOSYS/bin:$PATH	sendevent, autorep, jil not found

🎯 Key Takeaways

AUTOSERV is the most important environment variable — wrong value = wrong instance. No error. No warning.
Put AUTOSERV in your shell prompt. Always visible. Never forgotten.
Port 7520 must be open between Event Processor and every agent. Closed port = jobs stay PENDING.
Test job on local server proves nothing about remote agents. Test EACH agent machine.
8GB RAM minimum, 16GB+ for production. Underprovisioning causes silent performance collapse.
First command after SSH: autoflags -a. Verify BEFORE any destructive operation.

⚠ Common Mistakes to Avoid

✕Not verifying AUTOSERV before running commands

Symptom

Engineer deletes jobs from PRD while thinking they're in DEV. No error messages. No 'are you sure' prompt. Recovery takes hours.

Fix

export PS1='\u@\h:$AUTOSERV \w\$ ' — display instance in prompt. Run autoflags -a before every destructive session.

✕Installing agents without opening firewall port 7520

Symptom

Agent shows INACTIVE in autorep -M %. Jobs assigned to that agent stay PENDING forever. No error in job logs — the Event Processor can't contact the agent at all.

Fix

Verify port connectivity: telnet agent-host 7520. Open firewall between Event Processor and every agent. Test with autoping -m after fix.

✕Not creating dedicated service accounts per environment

Symptom

Same OS account (autosys) connects to DEV and PRD. Engineer sources a profile with AUTOSERV=PRD, thinks they're in DEV, runs destructive JIL against production.

Fix

Create separate OS accounts: autosys_dev, autosys_qat, autosys_prd. Each account has its own .bash_profile with the correct AUTOSERV. No shared accounts.

✕Forgetting to clean up test jobs

Symptom

Months later, autorep shows dozens of test jobs (INSTALL_TEST, TEST_JOB, TEMP_JOB). No one knows which are safe to delete. The environment is cluttered.

Fix

After verification: echo 'delete_job: INSTALL_TEST' | jil. Add test job cleanup to your install checklist.

✕Assuming chk_auto_up passing means agents are reachable

Symptom

Install verified on server. First real job on remote agent fails. chk_auto_up still says RUNNING. The Event Processor is fine — the agent network path isn't.

Fix

Test EACH agent machine individually: autoping -m remote-agent. If fails, check port 7520 and agent service on remote host.

Interview Questions on This Topic

QWhat environment variables does AutoSys use and what does each control?JuniorReveal
Three primary environment variables: - AUTOSERV: The instance name (e.g., ACE, PRD, DEV). Determines which database the commands connect to. This is the most critical — wrong value affects everything. - AUTOSYS: Installation directory path (e.g., /opt/CA/WorkloadAutomationAE). Binaries like sendevent, autorep, jil live in $AUTOSYS/bin. - AUTOUSER: User data and log directory. Event processor logs are at $AUTOUSER/out/event_demon.$AUTOSERV. Also ensure PATH includes $AUTOSYS/bin. Without it, AutoSys commands won't be found. Best practice: Set these in the AutoSys service account's .bash_profile and display AUTOSERV in the shell prompt to avoid instance confusion.
QWhat is the AUTOSERV variable in AutoSys?JuniorReveal
AUTOSERV is the AutoSys instance identifier. It tells every AutoSys command which database (Event Server) to connect to. If you have DEV, QAT, and PRD AutoSys instances on the same server, each has a different AUTOSERV value. Set AUTOSERV correctly in your shell environment before running any command. Critical safety issue: There is no warning if AUTOSERV is set to the wrong value. You can delete PRD jobs while thinking you're in DEV. AutoSys commands assume you know what you're doing. Best practice: Put AUTOSERV in your command prompt: export PS1='[$AUTOSERV] \u@\h\$ '. Always verify with autoflags -a before destructive operations.
QWhat port does the AutoSys Event Processor use to communicate with agents?JuniorReveal
Default port is 7520. The Event Processor (on the AutoSys server) initiates connections to each Remote Agent on this port. The agent listens on 7520. Implication: Firewalls must allow outbound traffic from the AutoSys server to every agent machine on port 7520. If the port is blocked, agents show as INACTIVE and jobs stay PENDING. Verification: - From AutoSys server: telnet agent-host 7520 - In AutoSys: autoping -m agent-host If autoping fails, check firewall rules and confirm the agent service is running on the remote host.
QHow do you verify an AutoSys installation is working correctly?Mid-levelReveal
Run this 5-step verification checklist: 1. chk_auto_up -A — Event Processor must show RUNNING 2. autoflags -a — Must connect to Event Server without errors, shows instance name 3. autorep -M % — Lists all registered agents. Each should show ACTIVE status 4. Test job on local server: Insert a simple CMD job (echo to log file). Force-start it. Verify SUCCESS and log file content. 5. Test job on remote agent: Same test, but set machine to a remote agent. Verify it runs. Critical: Step 5 is where most installs fail. Testing on the server proves nothing about remote agents. Clean up test jobs: echo 'delete_job: TEST_JOB' | jil
QWhat would you check first if AutoSys was freshly installed but jobs aren't running?Mid-levelReveal
Prioritized checklist for a non-working install: 1. Check AUTOSERV: echo $AUTOSERV and autoflags -a. Are you connected to the instance you expect? 2. Check Event Processor: chk_auto_up -A. If not running, check log: tail -100 $AUTOUSER/out/event_demon.$AUTOSERV. 3. Check agent connectivity: autorep -M %. If agents show INACTIVE, test port: telnet agent-host 7520. Most common issue: firewall blocking port 7520. 4. Check a specific job: autorep -J JOBNAME -d. Look for status, last start time, exit code. 5. Check event_demon log: grep JOBNAME $AUTOUSER/out/event_demon.$AUTOSERV. Shows condition evaluation and trigger attempts. 90% of post-install issues are either: wrong AUTOSERV, Event Processor not started, or port 7520 blocked.
QHow do you safely manage multiple AutoSys instances (DEV, QAT, PRD) on the same server?SeniorReveal
Three-layer isolation strategy: 1. Separate OS service accounts - autosys_dev, autosys_qat, autosys_prd - Each account's .bash_profile sets AUTOSERV to its correct instance - No shared accounts. No exceptions. 2. Instance in the prompt ``bash export PS1='\u@\h:$AUTOSERV \w\$ '`Always visible. No 'oops, wrong window' mistakes. 3. Pre-flight verification in scripts First line of any destructive JIL script:`bash autoflags -a | grep Instance echo "You are about to modify $AUTOSERV. Type YES to continue" read confirmation`` 4. Separate log directories Each AUTOSERV uses its own $AUTOUSER path. Logs don't mix. Common failure: Engineer logs into the PRD account, thinks they're in DEV because they're on the same server. The prompt shows the instance. If they ignore it, they're in trouble. Training and muscle memory are the only real preventatives.

Frequently Asked Questions

What is AUTOSERV in AutoSys?

AUTOSERV is an environment variable that identifies the AutoSys instance name. It's used by all AutoSys commands to know which database instance to connect to. If you have DEV, QAT, and PRD instances, each will have a different AUTOSERV value.

Critical safety issue: There is no safety prompt. If AUTOSERV is wrong, you'll run commands against the wrong environment. Always verify with autoflags -a before destructive operations.

What port does AutoSys use?

The default port for AutoSys agent communication is 7520. This port must be open in firewalls between the AutoSys Event Processor (server) and every agent machine. If the port is blocked, agents show as INACTIVE and jobs stay PENDING forever.

The WCC web interface uses port 8080 (or 8443 for HTTPS) by default.

How do I check if AutoSys is running?

Two commands

chk_auto_up -A checks Event Processor status (RUNNING/STOPPED)
autoflags -a checks overall system status including Event Server connection

Both commands are available from the command line on the AutoSys server after sourcing the AutoSys environment variables.

Can AutoSys run on Linux?

Yes. AutoSys fully supports RHEL and CentOS Linux for both the server and agent components. It also supports Windows Server, AIX, and Solaris for agent machines. The Event Processor and Event Server typically run on Linux in production environments.

How many AutoSys instances can run on one server?

Multiple instances can run on the same physical or virtual server. Each instance has its own AUTOSERV identifier and its own database (Event Server). This is commonly used to have separate DEV, QAT, and PRD AutoSys environments on the same hardware.

Safety requirement: Use separate OS service accounts for each instance (autosys_dev, autosys_prd). Shared accounts inevitably lead to 'oops, wrong instance' incidents.

What's the first thing I should do after SSH'ing into an AutoSys server?

Run autoflags -a and verify AUTOSERV. This tells you exactly which instance you're connected to. Then check chk_auto_up -A to confirm the Event Processor is running.

This 5-second check prevents the most common mistake: thinking you're in DEV when you're actually in PRD. Put AUTOSERV in your prompt so you never forget.

🔥

Naren Founder & Author

Developer and founder of TheCodeForge. I built this site because I was tired of tutorials that explain what to type without explaining why it works. Every article here is written to make concepts actually click.

About Naren Get in touch

Forged with 🔥 at TheCodeForge.io — Where Developers Are Forged