This guide explains what each feature is for, the exact sequence to use it, what details matter, and what to check when a workflow does not behave the way you expect.
Connections
Providers are the accounts ForgedBase uses for infrastructure, source control, DNS, and future storage workflows. Use them first, because servers and repository-backed sites depend on synced provider metadata.
Go to Providers from the dashboard navigation. Review the available provider categories: server providers, source control providers, storage providers, and entries marked as coming soon.
Choose Connect on the provider you want to use. For OAuth providers, finish the provider authorization flow and return to ForgedBase after the callback succeeds.
After connection, let ForgedBase sync account metadata. Server providers sync projects, regions, sizes, images, SSH keys, and provider account details. Source control providers expose repositories, branches, tags, deploy keys, and webhooks.
Open the provider detail page and check the status pill, latest sync time, metadata counts, recent activity, and any advanced error details before using the provider in a create flow.
DigitalOcean is used for server provisioning and DNS automation when the account owns the relevant zone.
GitHub and GitLab are used for repository-backed site creation, deployment webhooks, deploy keys, branch selection, tag selection, and source archive retrieval.
Provider actions are locked while sync is running so disconnect, sync, or metadata refresh actions do not overlap the active job.
If a provider is connected but unusable in a form, the most common cause is missing or failed metadata sync rather than the OAuth connection itself.
✓ The provider status says connected or ready.
✓ The metadata needed by the next workflow is present: projects, regions, sizes, images, SSH keys, repositories, branches, or tags.
✓ The recent activity list does not show a failed sync that still needs attention.
Infrastructure
Servers host sites, databases, queues, schedulers, SFTP access, SSH keys, PHP versions, commands, and maintenance actions. Create servers from synced provider metadata and then operate them from the server detail workspace.
Open Servers, choose Create, then select a connected server provider. If the provider is not ready, return to Providers and sync it first.
Select the provider project, region, size, Ubuntu image, provider SSH key, hostname, and friendly server name. These choices come from synced provider records.
Select runtime services such as PHP, database engine, Redis, Supervisor, firewall defaults, and package options. The guided flow only exposes tested runtime combinations for the selected image.
Submit the server. ForgedBase creates the server record, queues the infrastructure job, redirects to the provisioning workspace, and updates progress as the queue worker advances each step.
Use the server detail tabs for PHP versions, storage, backups, SSH, SFTP, commands, maintenance, settings, and activity. Later installs do not belong to the initial provisioning screen; they show progress where they were started.
Nginx is the default web server for app-server provisioning.
PHP versions can be installed during creation or added later from the PHP workspace. CLI defaults and site defaults are controlled separately.
Server maintenance actions can queue restarts, provider status refreshes, package refreshes, service restarts, and reboots.
Server activity is the best place to inspect exact context when a provisioning pill is too compact to explain a failure.
✓ Queue workers are running when provisioning stays queued.
✓ The server has a public IPv4 address before SSH-dependent actions are expected to work.
✓ The selected provider SSH key exists in the provider account and was attached during server creation.
Applications
Sites combine application preset, server, source control, domain strategy, runtime options, database attachment, deployment settings, environment variables, processes, schedulers, and notifications.
Start with Laravel, MyBB, plain PHP, or static HTML. The preset sets sensible defaults such as type, document root, database expectations, and blueprint behavior.
Select a source control provider, repository mode, repository, branch or tag, composer dependency behavior, and whether ForgedBase should generate a deploy key.
Pick a ready server with the runtime support needed by the site. If only one ready server exists, the create flow can preselect it.
Enter the primary domain, optionally reserve a ForgedBase platform subdomain, choose wildcard behavior, configure www redirect mode, and decide whether provider DNS should be automatically configured.
Select PHP version, document root, database attachment, new database credentials when needed, and review the resulting launch plan before queuing site provisioning.
After provisioning, use the site workspace for overview, deployments, environment, domains, SSL, network/security, processes, commands, scheduled jobs, notifications, and settings.
ForgedBase platform subdomains let a site open before a custom domain points correctly.
Document root defaults differ by preset, but can be adjusted from site runtime or settings areas.
Source control settings can be changed later, but deployment behavior depends on repository access, deploy key state, selected reference, and webhook configuration.
Destructive site lifecycle actions are intentionally separated into danger settings and confirmation flows.
✓ The selected server is ready and has the PHP version required by the site.
✓ The domain is unique and a valid fully-qualified hostname, unless using the platform subdomain as the primary address.
✓ The repository and branch or tag are available from the connected source control account.
Release flow
Deployments fetch source code, run the configured deployment script, activate releases, record logs, and notify destinations. Use deployment history to understand what changed and where a run failed.
Connect a repository and generate or attach a deploy key so the server can read private code without broad account credentials.
Set the commands needed for your application, such as dependency installation, framework cache commands, migrations, build commands, symlink work, or queue restarts.
When supported, let ForgedBase install a repository webhook so commits can trigger deployments automatically. Keep webhook state visible from deployment settings.
Trigger a manual deployment or push to the configured branch. Watch the status pill, selected run details, logs, timing, and final outcome.
Use deployment history to inspect previous runs, compare failures, retain the right amount of history, and find the exact log output for a release.
Deployment notifications can be routed per site for success and failure events.
Deployment state reset is scoped to deployment state and does not rewrite the whole site record.
Branch and tag choices come from provider repository metadata and may need a refresh when newly created references are missing.
Deploy script failures usually need the run log, not just the final status.
✓ The repository is reachable from the selected source control provider.
✓ The deploy key exists and is accepted by the provider.
✓ The selected branch or tag matches the intended release source.
✓ The deployment script matches the site type and document root.
Network
Domain and SSL tools route traffic to the correct site, configure provider DNS records, manage platform domains, issue certificates, and renew certificates before expiry.
Open the site domain or network area, add a fully-qualified hostname, and decide whether it should be primary, secondary, wildcard-enabled, or redirected from www.
Point records at the selected server IP. When DigitalOcean DNS automation is available, ForgedBase can create or update the zone records and report whether the zone was created or reused.
Reserve a platform subdomain under the configured ForgedBase platform domain for immediate testing or as the primary domain when desired.
Request SSL once DNS is correct. Follow challenge state, certificate records, failure messages, and automatic renewal eligibility.
If DNS or SSL fails, inspect provider DNS results, challenge output, Let’s Encrypt rate-limit messages, and whether the domain points at the intended server or site.
Platform-domain SSL can be managed separately from custom-domain certificate issuance.
Wildcard choices change the DNS records ForgedBase expects and can affect certificate challenge requirements.
Disabled domain pages can be refreshed by operational commands when a domain is intentionally disabled.
Certificate renewal is queued by the scheduled renewal command when certificates are due.
✓ The domain resolves to the intended server before requesting SSL.
✓ Provider DNS automation has access to the correct zone.
✓ The certificate failure message does not indicate a temporary external rate limit.
Storage
Database features manage server-level engines, site database attachment, database records, users, credentials, local backups, scheduled backups, and plan-based backup access.
Install MySQL or PostgreSQL during server creation or later from the server Storage tab. Later installs display progress inside Storage, not on the initial provisioning page.
Create a database with a name and generated or supplied credentials. Store the generated credentials shown by the modal before closing it.
Add users with database scope, read-only options, generated password details, and visible relationship to databases and sites.
During site creation or settings updates, choose an existing database or create one when the application preset expects database access.
Use backup tools to create on-demand backups, inspect backup records, download local backups, delete old backups, and schedule recurring backups when the plan allows it.
Protected database users are called out so you do not accidentally treat system-managed access like ordinary credentials.
Backup schedules are queued by a scheduler command that looks for due server database backup schedules.
Database backup access is plan-aware, but existing database records remain visible even when management is limited.
Remote storage destinations are represented in the provider and permission model for future backup destinations.
✓ The database service is installed and ready before creating databases.
✓ The workspace plan allows backup management when creating schedules.
✓ Credentials are copied from the modal before leaving the generated credentials screen.
Access
Access features control who and what can connect to servers or repositories: global SSH keys, server-only SSH keys, provider SSH keys, SFTP accounts, generated credentials, and deploy keys.
Open SSH Keys, paste a complete OpenSSH public key line, name it clearly, and save it. ForgedBase normalizes the key and prevents duplicate account-wide keys.
When a global key is added or removed, ForgedBase queues background jobs for visible servers. Servers that are still provisioning may wait until the public IP and provisioning key are available.
From a server page, add a scoped key when access should stay limited to that one server instead of being installed everywhere.
Open server SFTP settings, choose username, directory, access mode, authentication type, optional public key or password, recipient email, and whether to email credentials.
For repository-backed sites, allow ForgedBase to generate deploy keys so deployment can fetch code without using personal account credentials on the server.
Provider SSH keys are managed in the cloud provider account; ForgedBase shows them and uses them during infrastructure creation.
SSH activity records whether an install was completed, skipped, already present, removed, or failed.
SFTP accounts can be edited later without changing unrelated SSH or provider keys.
Generated server or database credentials are shown through scoped modals and emails where appropriate.
✓ Public keys begin with a supported OpenSSH key type and include the full key body.
✓ Server-only access is used for exceptions; global access is used for account-wide operator access.
✓ SFTP directory scope matches the access level intended for that person or automation.
Runtime operations
Runtime operations let you run commands, configure queue workers, manage scheduled jobs, and keep long-running process state near the site or server that owns it.
From a server command area, enter a command only when you have permission and need a server-level operation. Review the command run record afterward.
From a site command area, run commands in the site context so output and failure state stay attached to that site.
Choose process mode, name, command, working directory, process count, start seconds, stop seconds, stop signal, PHP version, queue connection, and queue name when configuring workers.
Create scheduled commands for recurring site tasks. Keep the command clear, scoped, and connected to the site workflow that owns it.
After changing environment or runtime settings, restart queues or relevant services when the page offers that option, then confirm activity and status reflect the change.
Supervisor-backed processes support long-running workers and queue behavior.
Command outputs belong in command run records rather than scattered notes.
Process, scheduler, and command controls are permission-gated.
Queue workers and scheduler support are part of the core launch workflow.
✓ The command belongs at the server level or site level before you run it.
✓ The working directory and PHP version match the application.
✓ The process name and queue name are specific enough to understand later.
Notifications
Integrations connect deployment, file transfer, and workspace events to Slack, Discord, Telegram, webhooks, SMS, and future destinations. Site notification settings decide which connected destinations receive site events.
Review available integrations and your workspace plan access. Free workspaces include Slack access; paid plans can unlock all integrations configured by billing.
Use the provider connect flow for Slack or Discord, finish authorization, and return to ForgedBase after the callback completes.
For Telegram, validate bot token and chat ID. For webhooks, provide an endpoint URL and optional signing secret. For SMS, configure ClickSend API credentials and recipients.
Use test delivery or validation actions before saving when the integration supports it. Fix token, URL, recipient, or chat errors before relying on site notifications.
Open site notification settings, enable the integration type, choose connected destinations, and select the site events that should send notifications.
Webhook signing secrets are stored as connection credentials and can be used to verify deliveries.
Telegram validation checks both bot identity and destination chat access.
SMS delivery depends on ClickSend API credentials, sender settings, and recipient formatting.
Integration connections are workspace-scoped and permission-gated.
✓ The workspace plan includes the integration type.
✓ The destination is connected before it is selected on a site.
✓ Success and failure notification toggles match the signal level your team wants.
Workspace
Workspace features control who can operate infrastructure and what capacity the workspace has. Billing changes capacity; roles and permissions determine what each person can see or do.
Open Team, create an invitation, choose role or permissions, and send the tokenized invite. The recipient accepts through the public invitation route.
Use Admin for broad management except owner-sensitive billing, Developer for site and deployment work, Operator for infrastructure operation without destructive provider actions, Viewer for read-only access, or Custom for exact permission control.
Use workspace switching to operate within the correct owner context. Resource queries, limits, and permissions are scoped to the active workspace.
Open Billing to understand server limit, site limit, team access, team member limit, database backup access, and integration access for the active plan.
Use Stripe checkout or the billing portal for paid plan changes, invoices, payment methods, refunds, and subscription management. ForgedBase updates workspace state after Stripe confirms the change.
Free includes one server and one site with core launch features.
Pro includes two servers, unlimited sites, backups, all integrations, and limited team access.
Enterprise removes server, site, and team member limits while keeping the same launch workflow.
Downgrades do not delete existing resources; over-limit actions are restricted until the workspace fits the plan.
✓ The person has the exact permission needed before troubleshooting a missing action button.
✓ The active workspace is the one whose resources you intend to change.
✓ Plan limit modals are capacity warnings, not deletion warnings.
Visibility
Activity feeds, provisioning pills, Reverb updates, queue workers, failed job inspection, and scoped failure messages explain what happened without making you chase logs first.
When something looks stuck, open the provider, server, site, deployment, database, domain, certificate, integration, or billing page where the action started.
Use the compact state first: queued, running, syncing, provisioning, failed, skipped, ready, connected, or completed. Then open the detailed run or activity row for context.
Review activity records for provider syncs, server provisioning, domain routing, SSL, deployment runs, maintenance actions, SSH sync, billing, and integration events.
If the underlying job completed but the UI did not update, check Reverb, Echo listeners, broadcasting, queue workers, and whether the page is listening to the expected channel.
For failed jobs, inspect the failure message, selected run, provider details, command output, or deployment log before retrying. Retry only when the cause is understood or transient.
Realtime event names, channel names, payload keys, listener names, and provisioning order are high-risk and should stay stable.
Provisioning pills are deliberately local to the workflow that owns the job.
Activity feeds are an audit trail for both successful and failed operational work.
Queue health matters for provider syncs, server work, site work, deployments, backups, certificates, and notifications.
✓ Queue workers are consuming the correct queues.
✓ Reverb is running when live progress is expected.
✓ The latest failure belongs to the action being retried, not an older run.
Need the shorter version?
The overview page keeps the same platform areas but summarizes them for faster scanning.