How aceakira1017/aternos-afkbot works
Purpose and Entry Point
This is a Node.js AFK bot deployment for keeping an offline-mode Minecraft/Aternos server occupied. The process entry point is index.js; deployment is intended to run it as a long-lived Render web service.
Bot Runtime
index.js is the central runtime boundary: it loads connection settings, creates and maintains the Minecraft bot connection, and must expose or host enough HTTP behavior for the deployment platform to remain reachable. The Node dependency/runtime definition is in package.json.
Relevant paths: index.js, package.json
Minecraft Connection Configuration
config.json supplies server-specific connection inputs: target host/IP, port, bot username, and likely protocol version. This separates user-provided server identity from the bot runtime.
Relevant paths: config.json, index.js
Connection and AFK Lifecycle
The main control flow is: process startup → read configuration → connect bot to the target Minecraft server → keep the client present/active → handle disconnects or errors sufficiently for a hosted process to remain operational. Minecraft server compatibility, especially protocol version support, is a material operational boundary.
Relevant paths: index.js, config.json
Hosting Keep-Alive Boundary
The application is deployed as a web service on Render, not merely as a standalone bot process. Render can spin down idle free-tier services, so an external HTTP monitor is expected to periodically contact the service URL and keep the Node process available.
Relevant paths: Procfile, package.json, index.js
External Services and Constraints
• Minecraft/Aternos: destination server; requires online-mode=false according to the operating model.
• Render: hosts and runs the Node service.
• UptimeRobot: sends scheduled HTTP probes to prevent Render free-tier idling.
• GitHub: source/fork and deployment integration path.
Deployment Contract
The repository’s deployable unit is the Node process configured through package.json and potentially Procfile. User customization is limited primarily to config.json; code changes should preserve that configuration boundary and the HTTP reachability needed by external uptime monitoring.
Relevant paths: package.json, Procfile, config.json
Main entry points: index.js Bot Runtime · package.json Package Runtime · Procfile Process Declaration · config.json Connection Config
Components 11
Node Bot Service
- Package Runtime · Defines dependencies and process startup contract.
package.json - Process Declaration
Procfile - Connection Config · Provides host, port, username, and protocol version.
config.json - Bot Runtime · Hosts HTTP reachability and manages the Minecraft bot lifecycle.
index.js - HTTP Keep-Alive Endpoint · Keeps the hosted web service reachable.
index.js - Minecraft Connection · Connects, stays active, and handles disconnects or errors.
index.js - AFK Presence · Keeps the bot present on the target server.
index.js
External Platforms
- GitHub · Fork and deployment integration source.
- Render · Runs the long-lived Node web service.
- UptimeRobot · Periodically probes the service to prevent idling.
- Minecraft / Aternos · Offline-mode destination server.
Connections 11
- GitHub → Render: deploy integration
- Render → Package Runtime: runs Node service
- Render → Process Declaration: uses process command
- Package Runtime → Bot Runtime: starts
- Process Declaration → Bot Runtime: declares process
- Connection Config → Bot Runtime: loads settings
- Bot Runtime → HTTP Keep-Alive Endpoint: hosts
- Bot Runtime → Minecraft Connection: creates and maintains
- Minecraft Connection → AFK Presence: maintains presence
- Minecraft Connection → Minecraft / Aternos: connects using configured protocol
- UptimeRobot → HTTP Keep-Alive Endpoint: scheduled HTTP probes