All guides
Product handbook

StackPosts

Social publishing, scheduling, analytics, engagement and AI-assisted workflows.

InstallationAdministrationEveryday useOperations

Start here

Choose the instructions that match your role. You do not need to configure the server or create a developer app just to use a workspace that an administrator has already set up.

I manage this installation

Start with installation and requirements, then configure the site and its services.

Installation instructions →
I use an existing account

Sign in to the correct account/workspace, then follow the user guide for your task.

User features →
  1. Installing the product: follow this product’s installation chapter. Check its PHP, database, environment and installer requirements; do not copy setup commands from another product.
  2. Configuring the site: use Admin features for settings, users and available services. Keep site administration separate from ordinary workspace use.
  3. Connecting an external service: the administrator follows API setup and app review first. Users then connect their own permitted accounts.
  4. Using a feature: start with one controlled record, follow the task’s fields/buttons, then check the saved result before repeating the action with live records.
  5. Operating the installation: review operations for scheduled work, queues, backups and updates relevant to this product.
01 / Overview

Overview

Use this guide to set up a new isolated installation, prepare administrator settings, complete the main user workflows and operate the application. Route paths shown below are relative to your own application domain; configuration overrides can change some defaults.

Installing the application?

Start with Installation. Review the source version and outstanding setup inputs before running commands.

Setting up the business?

Follow Administration before inviting users or enabling external services.

Using the product?

Follow the User guide. Each workflow explains prerequisites, actions and expected results.

Maintaining the service?

Use Operations for background jobs, updates, backup and recovery.

These instructions are grounded in the pinned source snapshot. Runtime/UI acceptance is still pending; a documented expected result is not a completed test. Technical references and known missing inputs are collected at the end of this guide.

02 / Installation

Installation

Check the source and runtime

git clone https://github.com/markhubaai/stackposts.git stackposts-dd
cd stackposts-dd
git checkout --detach 1d0944d30f606782c9abf5b878224cdd3cd09b99

Verify the source manifest using the shared preparation procedure before changing this checkout. The source alias identifies the seller’s original directory; it does not establish equivalence to production or a specific customer archive.

Project requirements

Use the shared browser-installation procedure. The installer requires PHP 8.3.0 or newer; composer.json/lock constraints must also pass. Its configured writable paths are .env, bootstrap/cache and storage. MySQL is written as the installation database connection.

Extensions explicitly checked by this installer: ctype, fileinfo, filter, hash, json, mbstring, openssl, pdo, tokenizer, xml. Also provide pdo_mysql for the MySQL connection even where it is not in the explicit checklist. Optional media features can require additional extensions/binaries and must be checked independently.

Default configured purchase verification endpoint: https://stackposts.com/api/marketplace/install. This is a source default, not confirmation of service availability or permission to use production entitlements.

Accepted Setup fields: purchase_code, website_title, website_description, website_keywords, db_host, db_port, db_database, db_username, db_password, admin_name, admin_email, admin_username, admin_password, admin_timezone. The password confirmation must also be submitted. Complete the wizard instead of creating an administrator by database edits.

Prepare the server and source working copy
  1. Use a dedicated test host or VM with a separate database and per-project hostname. Do not point any snapshot at production databases, queues, mailboxes, payment accounts or customer channels.
  2. Obtain named read-only GitHub access through the repository owner’s access process. Use your normal authenticated Git workflow; never embed access tokens in clone URLs or documents.
  3. Check out the exact commit shown in the project guide. Keep the working copy and evidence logs separate from the local documentation folder.
  4. Verify every recorded file against the source manifest before making local changes. The manifest covers every other prepared file; its own hash and the Git commit should be recorded separately.
  5. Provision a PHP runtime satisfying composer.json and composer.lock, a reviewed Composer installation, required PHP extensions and a web server serving only public/. Use MySQL with pdo_mysql for the seven browser installers. Exact database server compatibility remains a test item.
  6. Create empty writable bootstrap/cache and storage runtime directories from the included placeholders. Give the application service account the required write access; do not make the entire code tree globally writable.
  7. Resolve the project-specific assets/build gap and obtain approved schema/anonymized fixtures where required. Do not copy an old release’s vendor, assets, database or .env into this snapshot without provenance and version checks.

Clone and pin each repository

Each project section gives the exact commands. A new source checkout is recommended so existing local application changes cannot be overwritten. The clone destination must be empty.

Verify prepared file hashes in PowerShell

Run from the root of the checked-out repository before installing dependencies or editing configuration. A clean Git status is a separate check.

$manifest = Get-Content -LiteralPath 'DD-SNAPSHOT.json' -Raw | ConvertFrom-Json -AsHashtable
foreach ($entry in $manifest.files) {
    $file = Join-Path (Get-Location) $entry.path
    if (-not (Test-Path -LiteralPath $file -PathType Leaf)) { throw "Missing: $($entry.path)" }
    if ((Get-FileHash -LiteralPath $file -Algorithm SHA256).Hash -ne $entry.sha256) {
        throw "Hash mismatch: $($entry.path)"
    }
}
git rev-parse HEAD
git status --short

Environment templates are inventories

The supplied .env.example files contain names only. They are not ready-to-run configurations. An empty variable can override a useful config default, so do not leave every listed variable blank and expect the application to work. Review config/*.php, use a minimal isolated configuration, then add values needed by enabled features. Provider options may also live in the database/admin UI.

Create .env only in a new source working copy. Use the values below as a starting checklist, replacing the hostname, database identity and password privately. APP_KEY is initially empty and must be generated locally; no application key is supplied in this document.

APP_NAME="Application Test"
APP_ENV=local
APP_DEBUG=false
APP_URL=https://project.example.test
APP_KEY=
APP_CIPHER=AES-256-CBC
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=REPLACE_WITH_ISOLATED_DATABASE
DB_USERNAME=REPLACE_WITH_ISOLATED_USER
DB_PASSWORD=SET_PRIVATELY
SESSION_DRIVER=file
CACHE_STORE=file
QUEUE_CONNECTION=sync
MAIL_MAILER=log

The file session/cache and sync queue values are temporary bootstrap choices, not the final worker configuration. The seven installers switch their final session, cache and queue backends to database unless explicitly configured otherwise. Keep workers stopped until fixtures and outbound destinations are controlled. Never regenerate APP_KEY on an existing installation.

Dependency installation is separate from the browser wizard

The Git snapshots exclude installed root vendor dependencies. Inspect Composer scripts and allowed plugins before running dependency installation. A complete customer release may already contain its matching vendor tree; the source snapshots do not. Review package scripts before any Node dependency install.

# Run only inside the isolated checkout after reviewing scripts/plugins.
composer install --no-dev --prefer-dist --no-interaction
composer check-platform-reqs --no-dev

# Fresh isolated installation only, once dependency bootstrapping works.
php artisan key:generate
php artisan config:clear

If post-autoload package discovery cannot boot because configuration or database-backed options are missing, retain the error. A reviewer may install with --no-scripts for diagnosis, but deferred package-discovery/scripts must be reviewed and completed after the missing configuration is supplied. Do not present --no-scripts as a finished deployment.

Complete the browser installer

This procedure applies to StackPosts, MarkHub, Waziper Official, FlowCRM AI, LocalBoost AI, LeadFlow AI and LinkQR Pro. The Store has its own procedure below. The observed wizard is Requirements → Setup → Finish, served by GET/POST /installer.

  1. Complete dependency, asset and fresh-environment preparation first. Point the virtual host at public/ and use HTTPS for provider-facing tests. In WAMP, use a dedicated virtual host; the v13/docs folder itself is not an application document root.
  2. Create a new empty MySQL database and its isolated user. The installer checks that it is fresh; do not import a production database or run seeders/migrations first.
  3. Open /installer and resolve every Requirements failure. PHP and the exact checked extensions are listed in each project section. Confirm .env, bootstrap/cache and storage can be written by the web process.
  4. At Setup, enter an valid installation purchase code, website title, database host/port/name/user/password and administrator name/email/username/password confirmation/timezone. Optional website description and keywords are also accepted.
  5. Submit once and record the result. The installer verifies the purchase, creates its application key, writes database settings, runs migrations, seeds configured defaults, creates the administrator/plan and marks installation complete.
  6. At Finish, sign in with the administrator you created. Confirm that /installer is no longer available as a fresh setup page and that the final session/cache/queue configuration is consistent.
  7. Configure SMTP, selected themes, plans, integrations, scheduler and workers, then execute the project’s acceptance checks. Local sign-in is not provider acceptance.

A failed install can leave partially created database tables even if the previous .env is restored. Preserve redacted evidence and have the reviewer reset only the confirmed disposable test database before a clean retry. Never use migrate:fresh or delete a production database as troubleshooting.

Prepare the matching interface assets

No root package.json/build recipe or compiled public/build tree is included. The Composer setup script nevertheless refers to npm install/build. Ask the seller for the build inputs and matching assets for this exact commit, or a documented static-asset serving path. Do not create a guessed npm script or reuse a different product’s assets.

03 / Administration

Admin setup

Work as an authorized administrator in the isolated installation. Configure one area at a time, save it, then verify its effect with an appropriate test user. Feature access can depend on both the subscription plan and the user’s workspace role.

1

Site and delivery settings

Set the public URL, timezone, branding and a controlled SMTP sender. Verify the chosen guest/app theme and its compiled assets before inviting users.

2

Plans and publishing access

Define plans, quotas and enabled publishing/AI/add-on capabilities. Create a test owner and a restricted teammate, then compare permissions.

3

Provider integrations

Configure each social provider separately. Record app identity, callback/redirect settings, permissions, review status and whether the mechanism is Official or Unofficial.

4

Automation and spending

Choose reviewer-owned AI projects and quotas. Review outgoing action destinations and enable the separate automation worker only after a controlled test.

Before inviting users

  • Check site identity, timezone and selected themes.
  • Test sign-in with an owner and a restricted teammate/customer.
  • Confirm the configured mail mode and recipient identity before sending invitations.
  • Verify plan/role limits and the workspace that owns each record.
  • Review any enabled external action, provider cost and recovery procedure.
Product configuration notes
  1. Configure the selected admin/app and public themes, site URL, timezone, user plans and SMTP after installation.
  2. Inventory each social connector separately: official API, unofficial mechanism, required permissions, app owner, redirect URL, webhook URL and review status. Module presence does not prove a working platform integration.
  3. For AI features, use reviewer-owned test projects and controlled budgets. Separate AI workflow jobs from the ordinary queue; the automation queue has its own connection and retry policy.
  4. Map separately sold add-ons and historical analytics modules to their source paths and package/version. Do not equate folder presence with a separately transferable licence.
04 / User guide

Use the features

Use the correct workspace and an account with the required plan and role. The workflows below describe the principal product tasks supported by the inspected routes and actions; they are not a manual for every optional module.

Workflow 01

Connect a social channel

/portal/channels

Before you start: An administrator has configured the provider app; your plan and workspace permit the connector.

What this feature does

Add an account that can be selected when composing a post.

Who can use it

A signed-in user with connector access in the correct workspace. The administrator must configure the provider first.

Fields and settings

Field or settingWhat to enter or check
Provider / account typeChoose the actual connector. Official and Unofficial are different connection methods.
Provider identityUse the test account, page, profile or channel that should own the posts.
Authorization / credentialsComplete the connector-specific setup. Keep tokens and passwords in the application/provider setup, not in this guide.
WorkspaceCheck the selected workspace before connecting. A connection in one workspace is not a connection for another.

Steps

  1. Open Channels in the correct workspace and choose the network/account type you need.
  2. Follow the connector’s displayed authorization or setup process using a test account you control. Official and Unofficial connectors have different requirements.
  3. Review the returned account identity and permissions before saving the connection.
  4. Return to Channels and confirm that the expected account appears in this workspace.
Expected result

The intended account is listed for the correct workspace. This alone does not prove publishing approval.

Check the result

  1. Open the channel list after connecting and check the account name and provider.
  2. Open the composer and confirm that the intended account can be selected.
  3. If the provider reports missing permissions, fix those permissions before testing publication.

If it does not work: If connection fails, check provider permissions/review status, callback URL and the selected account type; do not substitute another tenant’s credentials.

Workflow 02

Create and review a draft

/portal/publishing

Before you start: You can access Publishing and have a permitted channel if the draft requires one.

What this feature does

Store post content for editing before publication.

Who can use it

A workspace member who can use Publishing and access the selected content/accounts.

Fields and settings

Field or settingWhat to enter or check
Post textReview the caption and any links. The publishing composer validation allows a caption of up to 2,200 characters; network restrictions can be tighter.
MediaSelect the files and the intended image, carousel, reel, story or video type. Check that the chosen connector supports it.
Account selectionCheck the intended destinations even when saving a draft. The publishing validation requires at least one account when submitting publication.
Labels / campaign / notesUse these to organize the item. Notes in the composer are limited to 400 characters in its validation.

Steps

  1. Open the publishing calendar and start the composer for the intended date or account.
  2. Select the account(s), enter post content and add only media owned by the test workspace.
  3. Review network-specific options and choose the draft action rather than immediate publication.
  4. Open /portal/publishing/drafts, locate the saved item and check its content and selected accounts.
Expected result

The draft can be found and reviewed without an external publication.

Check the result

  1. Find the item in Drafts using the same workspace and filters.
  2. Reopen it and check text, media and account selection.
  3. Confirm that no provider publication was requested by the draft action.

If it does not work: If no draft is visible, check workspace, search/provider filters and whether the composer saved successfully.

Workflow 03

Schedule and monitor a post

/portal/publishing

Before you start: A controlled provider account is authorized; scheduler and relevant workers are running.

What this feature does

Run a publishing request at a chosen time and inspect its result for each destination.

Who can use it

A member allowed to publish to the selected accounts; scheduler and queue workers must be configured.

Fields and settings

Field or settingWhat to enter or check
AccountsSelect at least one account in the publishing composer.
Schedule modeThe source modes are immediately and specific_days_times. Use the scheduled mode for future slots.
Date/time slotsReview every slot and the displayed timezone before submitting.
Repeat ruleThe source supports none, weekday and weekly_custom. Review repeat days/end values where enabled.
Media / caption / network optionsReview the payload separately for each network. One network can reject content accepted by another.

Steps

  1. Open the composer or the intended post from Publishing.
  2. Select the permitted account(s), verify content/media and choose the required date/time and scheduling mode.
  3. Confirm the workspace/user timezone before submitting the schedule.
  4. Review /portal/publishing/queue and the calendar. After the due time, inspect actual provider result and any error.
Expected result

The scheduled record is visible and its outcome is traceable. A queued record is not a delivered post.

Check the result

  1. Review the post in the calendar and Queue before its scheduled time.
  2. After it runs, inspect each destination’s final result and available public post link.
  3. Do not recreate successful destinations when retrying a failed one.

If it does not work: If the post remains pending, inspect queue workers, cron, timezone, account token and provider limits before retrying.

05 / Operations

Operations

Background processing for this product

The installer’s final defaults use database sessions/cache/queues. Confirm the relevant tables exist, start a worker for the intended queue and register schedule:run once per minute as described in shared operations. Observe the installed schedule before enabling outbound jobs.

The automation connection is explicitly a separate database-backed lane; it must not inherit QUEUE_CONNECTION=sync. With the source defaults, a separate worker for connection automation and queue automation is needed when testing AI Workflows. The default retry_after is 360 seconds; the sample worker timeout below is shorter.

php artisan queue:work automation --queue=automation --tries=3 --timeout=300
Source paths relevant to scheduling
  • app/Social/SocialServiceProvider.php
  • modules/AppAiPublishing/Providers/AppAiPublishingServiceProvider.php
  • modules/AdminMarketplace/Providers/AdminMarketplaceServiceProvider.php
  • modules/AdminFaker/Support/AdminFakerService.php
  • modules/AdminFaker/Providers/AdminFakerServiceProvider.php
  • modules/AppAnalytics/Providers/AppAnalyticsServiceProvider.php
  • modules/AppAutomation/Providers/AppAutomationServiceProvider.php
  • modules/AppBusinessFinder/Providers/AppBusinessFinderServiceProvider.php
  • modules/AppPublishing/Providers/AppPublishingServiceProvider.php
  • modules/AppGoogleBusiness/Providers/AppGoogleBusinessServiceProvider.php
  • modules/AppPayments/Providers/AppPaymentsServiceProvider.php
  • modules/AppRssSchedules/Models/RssScheduleHistory.php
  • modules/AppRssSchedules/Support/InteractsWithRssSchedules.php
  • modules/AppRssSchedules/Services/RssScheduleService.php
  • modules/AppRssSchedules/Providers/AppRssSchedulesServiceProvider.php
  • modules/AppRssSchedules/Livewire/RssScheduleIndex.php
  • modules/AppRssSchedules/Livewire/RssScheduleForm.php
  • modules/AppRssSchedules/Console/Commands/DispatchQueuedRssSchedulesCommand.php
Scheduler workers and mail

Run these procedures only after the isolated installation and outbound configuration have been reviewed. Use the application service account and the same PHP runtime/configuration as the web process. The commands below are operating examples to adapt, not commands executed during documentation preparation.

Schedule discovery before activation

php artisan schedule:list
php artisan queue:failed
php artisan migrate:status

These commands boot the application and require working configuration. schedule:list shows registered schedules but not every external cron or a complete deployment inventory. Record results before enabling continuous processing.

Scheduler

On a Linux test host, configure one cron entry per application. Replace both absolute paths with the confirmed test runtime and checkout. Preserve restricted test logs; rotate them.

* * * * * cd /srv/dd/PROJECT_ROOT && /usr/bin/php artisan schedule:run >> /srv/dd/logs/PROJECT-scheduler.log 2>&1

On Windows/WAMP, create a Task Scheduler job repeating every minute: Program = the selected php.exe; Arguments = artisan schedule:run; Start in = the isolated repository root. Use an account with the required file/database permissions. Do not point the task at the seller’s v12 working installation.

Queue workers

php artisan queue:work database --queue=default --tries=3 --timeout=60

This example applies when the intended connection is database and the queue name is default. Use the actual connection, named queues and worker limits from each project/module. Keep timeout below retry_after to reduce duplicate processing; check timeout requirements for media/AI work. StackPosts automation needs its separate lane described in its project guide. Supervisor/systemd or an equivalent process manager must restart long-running workers; cron is not a worker manager.

Record queue tables/backend, queue names, retry policy, failed-job handling, concurrency and restart behavior. Do not run queue:retry all blindly: failed jobs may send messages, charge providers or repeat external changes. Review the target and idempotency before a controlled retry.

Mail and optional services

  • MAIL_MAILER=log records messages locally and does not prove SMTP delivery. Use a controlled SMTP inbox for authorized notification tests; protect/redact logs containing test personal data.
  • Redis, object storage, websocket/realtime services, media binaries and social/AI gateways are feature-specific. Determine need from enabled modules and configuration rather than provisioning every possible dependency.
  • A provider console, approval, billing method and valid token are separate dependencies. A successful local install does not establish API approval or delivery.
  • Use actual callback/redirect URLs produced by the configured application. This guide intentionally does not invent a generic webhook URL for every provider.
Updates backup and recovery

Before an update

  1. Record the current source commit, dependencies, active modules/themes, schema revision, configuration inventory and artifact hashes. Verify the target release and its change notes.
  2. Take an encrypted database backup, uploaded-file/product-artifact backup and a separately protected copy of application configuration/APP_KEY. Do not place these backups inside source repositories or this documentation folder.
  3. Perform a restore rehearsal into a separate disposable environment. A backup file that has never restored successfully is not acceptance evidence.
  4. Obtain the product-specific upgrade instructions and rehearse on a clone. Waziper’s referenced UPGRADE.md is missing from its snapshot; do not invent an upgrade path.
  5. Define the maintenance window, queue drain/stop procedure and rollback thresholds. Separate application rollback from schema/data rollback.

During an approved change

Use the seller-approved release/update mechanism and reviewed migration steps. Preserve the existing APP_KEY and customer data. Do not rerun the fresh installer on an existing installation. Rebuild only the assets belonging to the selected release, clear/rebuild applicable caches and restart workers so they load the new code.

# Operational examples after an approved isolated update; adapt to the release.
php artisan optimize:clear
php artisan queue:restart

Re-enabling workers can produce external effects. Confirm the test destinations first. Do not treat copying the previous application code back as a complete rollback if schema or customer data changed.

Post-update checks

  • Check login, authorization, active themes/static assets, uploads/downloads, cron, queued work and one product-specific user flow.
  • For Store/license changes, validate synthetic old-install activation/update behavior and download entitlement before any cutover.
  • For provider integrations, retain separate webhook/publish/delivery evidence and redact tokens and customer identifiers.
  • Record backups, restore outcome, downtime, errors, rollback decision and remaining gaps. Remove disposable test data according to your retention policy.

Acceptance checklist

These are checks for the person testing the installation, not completed test results. Retain timestamp, commit, environment, fixture identity, expected/actual result and redacted evidence for each.

  1. Create two isolated teams and confirm that posts, files and channel records are not visible across teams.
  2. Create and edit a draft without connecting a production social account; confirm scheduling/timezone behavior with a controlled fixture.
  3. With an approved test app only, connect one channel, publish one controlled post and inspect the resulting status and error record.
  4. Run one controlled AI workflow through the automation worker and demonstrate that it does not execute synchronously in the web request.
06 / Troubleshooting

Resolve common problems

Start with the visible error, record it without secret values and check the related setup area. Do not use destructive resets or permission bypasses to make a test appear successful.

SymptomChecksAvoid
Missing vendor/autoload.phpRoot dependencies are excluded. Review Composer scripts/plugins and install the locked dependencies in the isolated checkout.Copying vendor from another version or running composer update as a shortcut.
419 or missing application keyCheck APP_URL/HTTPS, cookie/session settings, writable runtime directories and a locally generated APP_KEY for this new installation.Regenerating an existing production APP_KEY or disabling CSRF globally.
500 or missing tableCheck the redacted application log, module activation, database configuration, installer state and whether the approved schema/defaults exist.Importing production data or running migrate:fresh without verifying the disposable target.
Unstyled page or missing manifestCheck the actual active theme, expected asset URL and its matching manifest/build. Several snapshots have documented missing build inputs.Assuming npm run build exists everywhere or using assets from an older v13 release.
Purchase-code verification failsConfirm the configured endpoint, valid test entitlement, outbound route and isolated-host identity with the seller. Record redacted HTTP status.Bypassing purchase checks, using a customer’s code or disabling certificate checks as a remedy.
Wizard refuses nonempty databaseUse a new isolated database; retain evidence of previous failed attempt and obtain approval before resetting the disposable test target.Reusing a customer/production database.
Jobs do not runConfirm QUEUE_CONNECTION, exact queue names, running worker, scheduler registrations and failed-job logs. Check the automation lane on StackPosts.Leaving sync as final automation configuration or retrying every failed job.
Email not receivedInspect MAIL_MAILER; log mail is not SMTP. Verify a controlled sender/inbox and message status.Sending test messages to customer lists.
Provider action or webhook failsConfirm actual app/account identity, permissions, review status, callback URL, signature setup and test recipient.Treating a source module or local health page as provider acceptance.
07 / Technical reference

Source version and technical reference

Repository
markhubaai/stackposts
Pinned commit
1d0944d30f606782c9abf5b878224cdd3cd09b99
Laravel lock
v13.2.0
PHP constraint
^8.3
Source alias
stackposts
Open exact source references at the pinned commit
Source pathSnapshot status
README.mdPresent
composer.jsonPresent
composer.lockPresent
config/database.phpPresent
config/queue.phpPresent
config/mail.phpPresent
config/modules.phpAbsent — not a working reference
bootstrap/app.phpPresent
routes/console.phpPresent
app/Installer/config/installer.phpPresent
app/Installer/routes/web.phpPresent
app/Installer/Http/Controllers/InstallerController.phpPresent
app/Installer/Support/InstallerService.phpPresent
app/Installer/Support/InstallerState.phpPresent
app/Installer/resources/views/index.blade.phpPresent
package.jsonAbsent — not a working reference
package-lock.jsonAbsent — not a working reference
scripts/build-theme.jsAbsent — not a working reference
resources/modules_statuses.jsonAbsent — not a working reference
Module source inventory (107 descriptors)

These are source module descriptor locations, not proof that each module is active, configured, sold separately, licensed or provider-approved.

modules/AdminAI
modules/AdminAITemplate
modules/AdminAITemplateCategories
modules/AdminBlogCategories
modules/AdminBlogs
modules/AdminBlogTags
modules/AdminCache
modules/AdminCaptcha
modules/AdminCoupons
modules/AdminCredits
modules/AdminCrons
modules/AdminDashboard
modules/AdminFaker
modules/AdminFaqs
modules/AdminLanguages
modules/AdminMailServer
modules/AdminManualPayments
modules/AdminMarketplace
modules/AdminNotifications
modules/AdminPaymentHistory
modules/AdminPaymentManualConfig
modules/AdminPaymentReport
modules/AdminPaymentSubscriptions
modules/AdminPlans
modules/AdminSupport
modules/AdminSystemInformation
modules/AdminThemes
modules/AdminUser
modules/AppAIAssistant
modules/AppAIBestTime
modules/AppAICampaignWizard
modules/AppAICompetitorWatch
modules/AppAIContent
modules/AppAIContentPlanner
modules/AppAIImage
modules/AppAiPublishing
modules/AppAIRepurpose
modules/AppAIReview
modules/AppAISemanticSearch
modules/AppAIStudio
modules/AppAITrendFinder
modules/AppAIVideo
modules/AppAIWorkflows
modules/AppAnalytics
modules/AppAnalyticsFacebook
modules/AppAnalyticsInstagram
modules/AppAnalyticsLinkedin
modules/AppAnalyticsThreads
modules/AppAnalyticsTiktok
modules/AppAnalyticsYoutube
modules/AppAutoComment
modules/AppAutomation
modules/AppAutoReply
modules/AppBilling
modules/AppBulkPosts
modules/AppBusinessFinder
modules/AppCaptions
modules/AppChannelDiscordChannels
modules/AppChannelFacebookPages
modules/AppChannelGBPLocations
modules/AppChannelInstagramProfiles
modules/AppChannelInstagramUnofficial
modules/AppChannelLinkedinPages
modules/AppChannelLinkedinProfiles
modules/AppChannelMastodonProfiles
modules/AppChannelOkGroups
modules/AppChannelPinterestBoards
modules/AppChannelRedditProfiles
modules/AppChannels
modules/AppChannelTelegramChannels
modules/AppChannelTelegramGroups
modules/AppChannelTelegramOauth
modules/AppChannelThreadsProfiles
modules/AppChannelTiktokProfiles
modules/AppChannelXProfiles
modules/AppChannelYoutubeChannels
modules/AppCredits
modules/AppDesignStudio
modules/AppDeveloperApi
modules/AppFiles
modules/AppGoogleBusiness
modules/AppGroups
modules/AppIntegrations
modules/AppLinkBio
modules/AppPayments
modules/AppProfile
modules/AppPublishing
modules/AppSocialInbox
modules/AppSocialListening
modules/AppSupport
modules/AppTeams
modules/AppUrlShorteners
modules/AppWatermark
modules/Payment2Checkout
modules/PaymentCCAvenue
modules/PaymentFlutterwave
modules/PaymentInstamojo
modules/PaymentIyzico
modules/PaymentPaypal
modules/PaymentPaystack
modules/PaymentPaytm
modules/PaymentPayTR
modules/PaymentPayU
modules/PaymentRazorpay
modules/PaymentSslCommerz
modules/PaymentStripe
modules/PaymentYooMoney
Names-only environment inventory (52 names)

Derived from the prepared .env.example. This is not a complete settings inventory and contains no secret values. Empty names must not be treated as a working .env.

APP_NAME
APP_ENV
APP_KEY
APP_DEBUG
APP_URL
APP_INSTALLED
APP_DEMO
APP_LOCALE
APP_FALLBACK_LOCALE
APP_FAKER_LOCALE
APP_MAINTENANCE_DRIVER
BCRYPT_ROUNDS
LOG_CHANNEL
LOG_STACK
LOG_DEPRECATIONS_CHANNEL
LOG_LEVEL
DB_CONNECTION
DB_HOST
DB_PORT
DB_DATABASE
DB_USERNAME
DB_PASSWORD
SESSION_DRIVER
SESSION_LIFETIME
SESSION_ENCRYPT
SESSION_PATH
SESSION_COOKIE
SESSION_SECURE_COOKIE
SESSION_DOMAIN
BROADCAST_CONNECTION
FILESYSTEM_DISK
QUEUE_CONNECTION
CACHE_STORE
MEMCACHED_HOST
REDIS_CLIENT
REDIS_HOST
REDIS_PASSWORD
REDIS_PORT
MAIL_MAILER
MAIL_SCHEME
MAIL_HOST
MAIL_PORT
MAIL_USERNAME
MAIL_PASSWORD
MAIL_FROM_ADDRESS
MAIL_FROM_NAME
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_DEFAULT_REGION
AWS_BUCKET
AWS_USE_PATH_STYLE_ENDPOINT
VITE_APP_NAME
Installation and provider checks
  • Confirm the exact application version and its required runtime.
  • Complete installation in a disposable environment before using production data.
  • Check scheduled jobs, queues, mail and backup/restore behavior.
  • Configure provider credentials and test each enabled external feature.
  • Keep actual test results separate from instructions and source inspection notes.

API setup and app review

For provider app creation, callback URLs, account connections and review submission, use the platform guides. The administrator configures the provider; workspace users connect their own authorized assets.