How to Host an AI-Generated Website

1. Identify what the AI actually produced

Before buying hosting, identify the runtime and dependencies. Ask the coding assistant to list the project type, entry point, database, required background services, environment variables and build command. Do not choose a VPS simply because ChatGPT, Claude, Cursor or another AI tool generated the project.

• Static HTML/CSS/JavaScript: usually deployable as ordinary website files.
• WordPress: use the managed WordPress/PHP workflow.
• PHP/MySQL: compatible with the normal GreatHosts web stack when its extensions and limits fit.
• Python: supported, but the application still has to fit the available managed runtime.
• NodeJS: the live GreatHosts CP exposes NodeJS instances. Depending on the selected plan, the capability may already be included; when it is not included, it can be ordered as an add-on on the shared-hosting plan. Exact current inclusion and pricing are shown in the product tables and CP before purchase.

2. Start with the smallest sensible environment

Shared hosting is the default starting point when the project can run inside the managed environment and does not need root access. Before moving to VPS, check whether the missing capability can simply be enabled or ordered on the current plan. KVM VPS becomes appropriate when the project needs unrestricted server control, stronger isolation, sustained resources, or system-level behavior that the managed environment does not provide.

• Shared hosting avoids operating-system administration.
• The documented shared CPU allowance starts at approximately 5% of server CPU on entry plans; some plans expose more.
• NodeJS, Redis, Memcached, Varnish and Supervisor may be included by plan; when they are not included, they can be ordered as add-ons on the shared-hosting plan. Needing one of them does not automatically mean the entire project needs a VPS.
• KVM VPS provides root-level control and dedicated virtual resources.
• Dedicated servers are for workloads that genuinely need dedicated hardware or substantially higher sustained resources.

3. Prepare the project for deployment

Production hosting should not contain development-only files or secrets. Build the production version locally where applicable, remove debug configuration, and keep credentials outside publicly served files whenever the application design permits.

• Use production dependencies only.
• Do not hard-code database passwords, API keys or mail credentials in public source files.
• Confirm the application expects the correct public/web root.
• Export the database separately if the project uses one.
• Keep a known-good local copy before the first upload.

4. Upload through GreatHosts CP

For ordinary websites, upload the project files or a ZIP archive through GreatHosts CP, extract them, and place the public site in the domain web root. GreatHosts uses /home/www as the hosting home path; a typical domain root is /home/www/domain.com.

• Upload or drag and drop the project/archive.
• Extract the archive inside the intended domain root.
• Confirm that index.html or the application entry file is at the expected level.
• Avoid an accidental extra folder such as /domain.com/project/project-files.

5. Configure databases and runtime

For PHP/MySQL projects, create a database and user in GreatHosts CP, import the database, then update the application configuration. The database host is localhost. Current verified MySQL choices include 5.7, 8.0 and 8.4; PHP is available through 8.5. Python versions are selectable through current 3.x releases including 3.13.

• Choose the runtime version required by the application rather than the newest version blindly.
• Use the application’s migration/install process when it has one.
• Test database encoding and timezone-sensitive behavior after import.
• If the project requires an extension or daemon not present in the managed environment, reassess whether KVM is the right tier.

6. Put HTTPS and DNS in place

Connect the domain, confirm its DNS points to the hosting service, then enable HTTPS. Free Let’s Encrypt is available for qualifying domains ordered through GreatHosts; paid certificates are annual products even when the associated domain is registered for multiple years.

• Wait for DNS changes to propagate before diagnosing HTTPS failures.
• Redirect HTTP to HTTPS only after the certificate is valid.
• Do not expose a staging hostname or temporary URL as the canonical production URL.

7. Validate before launch

Test the site as a real visitor and as an authenticated user if applicable. Check forms, email delivery, file uploads, database writes, mobile layout, 404 behavior and HTTPS. For dynamic applications, watch CPU usage and error logs after launch before deciding that the hosting tier is inadequate.

• Run a clean-browser test.
• Test at least one real form submission.
• Verify canonical URLs and HTTPS.
• Confirm backups are available before major post-launch changes.
• Upgrade based on measured workload, not anxiety about the fact that AI wrote the code.

Services related to this guide