How Sngine actually handles multiple sites

Sngine is a single-tenant PHP social network script. One installation serves one community, backed by one database and one set of configuration values. There is no built-in network mode, no shared user table across sites, and no admin toggle that spins up a second community from inside the dashboard. If you compare it to a platform with native multi-tenancy, Sngine simply does not expose that concept — each community is an independent copy of the code with its own config.php, its own MySQL schema, and its own license key registered to a specific domain.

This matters because the request usually comes in disguised. A customer asks for a "second site" or a "test version" and expects a switch somewhere in the AdminCP. There isn't one. What you build instead is a set of parallel installs that happen to live under the same hosting account. They share disk quota, the same PHP handler, and the same account-level resource limits, but logically they are strangers to each other. Understanding that boundary up front prevents the most common failure: pointing two document roots at the same files and then wondering why editing one community's theme breaks the other, or why sessions leak between the two.

The license model reinforces the separation. Sngine is sold through Envato/CodeCanyon as a Regular License per end product deployed to a single domain. A staging copy you use for testing before pushing changes live is generally acceptable, but a second public-facing community is a second product and needs its own license. Before you build anything, decide which instances are genuinely live sites (each needing a purchase code) and which are throwaway staging copies. The engineering steps below are identical either way; the licensing obligation is not.

Planning the domain and directory layout

On shared hosting every instance needs three things: a web address, a directory to live in, and a database. The cleanest arrangement on both cPanel Jupiter and DirectAdmin Evolution is to give each Sngine community a dedicated subdomain or addon domain, with a document root that is completely separate from every other install. Avoid subfolder installs under a single domain (for example example.com/community2) unless you have no alternative — Sngine writes absolute URLs everywhere, and rewrite rules from a parent install in the same document root will collide with the child.

A practical layout for two communities under one account looks like this:

/home/acctuser/community-a/   -> social-a.example.com
/home/acctuser/community-b/   -> social-b.example.com

In cPanel, open Domains (or Subdomains on older layouts), create social-a and social-b, and set each Document Root to the folders above. Critically, uncheck or clear the default that nests new subdomains inside public_html if you want them isolated — leaving a subdomain root inside the primary domain's root means the primary domain's .htaccess still applies to it. In DirectAdmin, use Account Manager > Domain Setup to add each domain, then create the subdomain under it; DirectAdmin places each domain's files under /home/acctuser/domains/domain.com/public_html, which gives you natural isolation per domain.

Next, provision one database per instance. In cPanel use MySQL Databases to create acctuser_snga and acctuser_sngb, create a distinct MySQL user for each, and grant each user ALL PRIVILEGES on only its own database. In DirectAdmin the equivalent is Account Manager > MySQL Management > Create new Database. Never share one database user across both communities — a leaked or compromised config on one site should not hand over the other's data. Record each database name, username, and password now; you will paste them into the matching install's config.

Deploying each separate instance

Each Sngine instance is installed independently. Upload the Sngine ZIP into the first instance's document root using cPanel File Manager (or DirectAdmin File Manager), select it, and use Extract so files land directly in the root rather than a nested folder. Repeat with a fresh upload for the second instance — do not copy a half-configured install sideways, because the cached values and the license binding travel with it and cause confusing errors.

Before running the web installer, confirm the PHP version per domain. In cPanel open MultiPHP Manager, select each domain individually, and set a supported version (PHP 8.1 or 8.2 for current Sngine releases). The PHP Selector under CloudLinux lets you enable required extensions — pdo_mysql, mbstring, gd, curl, zip, and fileinfo — on a per-account basis. Because the selector is account-wide, both communities inherit the same extension set, which is fine; the per-domain control you care about is the version assignment in MultiPHP Manager.

Run the installer for each by visiting https://social-a.example.com/ and following the setup wizard, entering that instance's own database credentials and admin account, then its Envato purchase code. Do the same at https://social-b.example.com/ with the second database and second purchase code. After both finish, lock down the installer footprint: in File Manager, remove or rename the install directory inside each root, and verify config.php in each instance points to the correct database.

If you need to raise limits for uploads or memory, do it per instance with a .user.ini file in that instance's document root rather than touching anything server-wide:

upload_max_filesize = 64M
post_max_size = 72M
memory_limit = 256M
max_execution_time = 120

Remember .user.ini changes are cached and apply after the user_ini.cache_ttl window (commonly 300 seconds), so wait a few minutes before testing. Each community's own .htaccess should remain the stock Sngine rewrite file shipped in that root; because the roots are separate, there is no cross-contamination of rewrite rules.

Keeping instances isolated and maintained

After both communities are live, isolation becomes an operational discipline rather than a one-time setting. Confirm that each install has distinct values in its database settings for cookie and session scope — Sngine derives session cookies from the configured domain, so two correctly separated subdomains will not share logins. If you ever notice a user logged into the wrong community, the usual cause is two document roots accidentally resolving to the same folder; check the Document Root fields in Domains again.

Diagnose problems per instance using that instance's own log. Sngine and LiteSpeed write PHP errors to an error_log file in the active script directory, so look in /home/acctuser/community-a/error_log for the first site and the matching path for the second. Keeping logs per directory makes it obvious which community threw a fatal error after an update. When you update the script, update each instance separately: back up its database through phpMyAdmin Export, upload the new files to that one root, and run its upgrade routine. There is no shared codebase to patch once, so plan maintenance windows per community.

Watch account-level resource consumption, since both communities draw from the same CloudLinux limits (CPU, EP, I/O, and MariaDB connections). Two busy social networks on an entry plan can exhaust the entity-process limit and trigger 508 errors on both at once. If growth pushes you there, the correct move is separating the heavier community onto its own hosting account or plan rather than trying to squeeze more out of shared limits you cannot raise as an unprivileged user. For the broader mechanics of moving or rebasing one of these installs to a new domain once it outgrows the shared account, the approach in our WoWonder multi-site and multiple instances guide maps cleanly onto Sngine, since both are single-tenant social scripts with the same per-domain, per-license constraints.