Local Server

MicroServer is a local Windows environment: Apache, PHP 8, MariaDB. Sites live in D:\MicroServer\www. The folder name matches the host name. This is not cloud hosting or a hosting panel; it is a stand where Microscript scripts can be installed before deployment to shared hosting or VDS.

If you searched for "Denver with PHP 8", this is the relevant replacement. Do not mix old Denver into this setup: Denver replacement.

Domain and folder

For a new project, create a project.loc directory in www and place index.php or unpack the script there. The host appears after hosts synchronization by the server. Open http://project.loc.

Do not use localhost/project as the main mode for our products. Script paths and redirects expect a virtual host. Details: virtual host *.loc.

Keep manuals and production-like scripts in different www folders. The manual catalog is a separate host, not a subfolder inside a shop.

PHP

The version is PHP 8.x from the package. Scripts need mysqli, mbstring, gd, and curl; they are usually already present. Check with phpinfo during diagnostics or through CLI. General product requirements: PHP/MySQL requirements.

If dependencies are installed through Composer, PHP must be in PATH: Composer on Windows.

HTTPS

Certificates are issued by the local MicroServer CA. The browser trusts them after the root certificate is installed into the system. Hosts for SSL are defined in server configuration, including config/server.json; sites can move from 80 to 443.

Local https is useful for secure cookies, redirects, webhooks, and mixed-content debugging. Details: HTTPS on local host. Production SSL is separate: SSL on a PHP site.

MariaDB database

MariaDB listens on 127.0.0.1:3306. Use a separate utf8mb4 database per project so dumps and rollbacks do not affect neighbors. Create a database with local phpMyAdmin.

In the script installer, database host is 127.0.0.1 or localhost. Access denied follows the same rules as production: database error.

Do not expose 3306 outside your local firewall without need. This is a local stand.

Script installation

1. Create the name.loc folder and place files in the host root.
2. Create an empty database and user.
3. Run the installer in a browser.
4. Check the admin panel and one file upload.

Full order: script installation. White screen means log: 500 error.

Ports and conflicts

If OpenServer, XAMPP, or Docker with nginx runs in parallel, ports 80, 443, or 3306 may be busy. MicroServer may fail to start or MySQL may refuse connection. Stop the extra stack. One local server per machine is enough.

From local to production

When the stand works, migrate to hosting: migration, dump: MySQL migration, backup before experiments: backup. Platform choice: hosting or VDS.

Cron locally is not always required for full production imitation; production tasks will be configured separately: cron.

Practical www structure

Keep one project per host. Example:

• board.loc is a classifieds board;
• shop.loc is a shop;
• manual.ms.loc is the manuals;
• test-board.loc is a copy for risky experiments.

Copy a production dump to test-board.loc and edit only the test config. Import with phpMyAdmin; dump logic: MySQL migration.

Logs and debugging

A white screen on *.loc is debugged like on a VDS: read error_log, do not reinstall the stack. Enable display_errors only locally and only during diagnosis. If a production dump is used, avoid exposing paths and SQL in the browser.

500 checklist: 500 error. Typical Access denied during installation: database error.

Mail locally

mail() from a Windows stand often goes nowhere. For mail tests, read transport logs, configure SMTP to a test mailbox, or use a catcher. Do not call it a script bug when local Windows is not a mail relay.

Stand performance

MicroServer on a weak laptop with antivirus scanning every PHP file may feel slow in admin. Exclusions for www and stack processes help. Do not raise memory_limit to 2G just because the local stand is slow.

Xdebug is useful only when debugging. Keeping it always enabled on every request makes the script feel heavy.

Synchronization with production

The local stand is not a customer git server. Agree on the source of truth: release archive, repository, or production export. Blind FTP back and forth without a database dump causes order mismatch.

Before deployment, test home page, readable URLs, admin, file upload, and mail form if configured. Then migrate: script migration.

HTTPS and cookies

If production cabinet will use https only, enable local SSL once and test login: local HTTPS. Secure-cookie issues are easier to catch before deployment. Production certificate: SSL on site.

Composer and dependencies

If a vendor folder is needed, install Composer for the same PHP used by the server: Composer on Windows. Do not mix php.exe from two stacks in one PATH. Module requirements: requirements.

Virtual hosts without manual httpd.conf work: *.loc. If you came from a Denver search, redirect yourself here: Denver PHP 8.

If the server does not start after a Windows update, first check whether IIS or a web publishing service occupied 80/443. Then check antivirus quarantine for httpd or php. Third, review config changes. When Apache responds again but a specific project does not, diagnose the project: 500, database, installation. The same log-reading skills help on Linux VDS: VDS, Nginx. A local backup before hard experiments is useful too: backup.