One of the most common questions buyers ask is whether Orkely can run on ordinary shared hosting. The short answer is yes. If your host supports modern PHP, MySQL or MariaDB, and standard file uploads, you can usually get the app running without needing a custom server stack.
This guide is not just a checklist. It is the practical order of operations that makes shared-hosting installs smoother, especially if you are using cPanel and want the cleanest possible first deploy.
1. Start with the basics: hosting, database, and domain
Before uploading anything, confirm three things. First, your hosting account has a recent PHP version available. Second, you can create a fresh database and database user in cPanel. Third, your domain or subdomain points to the right folder. Those are the only requirements that truly block installation.
If you are still comparing whether self-hosting is worth this extra setup step, read why self-hosted software is making a comeback. In practice, the setup is usually simpler than people expect.
2. Upload the package exactly once and keep the structure intact
Use the package ZIP as delivered. Upload it to the target folder, extract it, and make sure the project structure stays intact. Do not flatten folders manually. In particular, keep the public, vendor, storage, and database directories where they belong.
If your host points the domain directly to the project root, Orkely’s root .htaccess can rewrite into public/. If the host allows the document root to point straight at public/, that is still the cleaner option. Either way, make sure your Apache rules are present and that symlink support is allowed.
3. Create the database before running the installer
The installer expects an existing, empty database. In cPanel, create the database, create a database user, and assign that user full privileges to the database. It sounds obvious, but this is where many “mystery” install errors begin. Most of the time the issue is not the app. It is simply a missing privilege or a typo in the database name.
Once that is ready, open /installer/ in the browser. The installer is designed to write the environment file, import the schema, create the admin account, and lock itself afterward.
4. Don’t skip the post-install checks
A successful installer screen is a great sign, but there are still a few quick checks worth doing before you call the deployment finished:
- Confirm the homepage and login page both load correctly.
- Log in with the admin account you created during setup.
- Visit the settings area and test email delivery.
- Verify SSL and your final domain URL are correct.
- Confirm that public storage links work if the app needs uploads or logos.
These checks matter because they catch the shared-hosting issues that happen after the database import, not before it: permissions, path mismatches, SSL drift, and document-root confusion.
5. Shared hosting success usually comes down to details, not power
Teams often assume a shared-hosting problem means the server is too weak. In reality, the common blockers are smaller and more boring: wrong permissions after ZIP extraction, missing symlink support, bad mail credentials, or an outdated sitemap and URL configuration.
If your business is still running core workflows in spreadsheets while you figure out infrastructure, it is worth reading the warning signs you have outgrown spreadsheets. Many teams delay the move because they overestimate the technical overhead.
6. Finish with email, branding, and cleanup
Once the install is working, finish the setup properly. Add your SMTP settings, test outgoing mail, upload branding assets, and remove anything that should not remain exposed. That includes deleting the installer directory after installation if you do not need it anymore.
From there, the best next step is usually operational, not technical: review the feature set, decide how you want to structure your clients and projects, and then invite the first real users.