From a cloud editor to a live client website

1. Create the source repository

Use one private repository per client, with a clear name such as Reviewfy-LLC/client-example-website. The repository is the editable source of truth, not a screenshot or a preview link from the editor.

1. In GitHub, select New repository, choose Reviewfy-LLC as owner, use a clear client-specific name, and select Private. Approved organization members can create repositories. Creating one gives you administration of that repository; you do not need organization-owner or cluster access.
2. Connect your cloud editor to that repository, or export its project and upload the files using GitHub's Add file → Upload files. Preserve the folder structure.
3. Commit and push to main. A plain HTML site needs index.html and its asset folders. A build-based project needs its source, package.json, and the dependency lockfile used by its build.
4. The organization’s Reviewfy LLC Deploy App is installed with read-only Contents and Metadata access for current and future repositories. A new repository under Reviewfy-LLC is available to the App automatically. Your own GitHub account must also have access to that repository. Both checks must pass before a build. Repositories hosted elsewhere need the administrator to arrange App installation first.

Commit an appropriate .gitignore. Keep node_modules, local environment files, API keys and private credentials out of the repository and published files. Client-side environment values are public once built; use public configuration only. A backend API or server-side secret needs a separate approved service.

The workspace publishes static sites: plain HTML, Astro static sites, Vite/React/Vue builds, and Next.js static exports. A project requiring a continuously running server, server-side rendering, API routes or server actions needs an administrator to arrange a different runtime.

2. Create the client site

1. Open Reviewfy Deploy and sign in with your approved GitHub account.
2. Select Create site and enter the client / site name.
3. Search and select the client's GitHub repository from the list. If you just created it, select Refresh repositories.
4. Wait for the setup check. The panel detects HTML, Astro, Vite/React/Vue or a Next.js static export, chooses the repository's default branch, and fills in build settings. If the repository contains several projects, choose its Website folder.
5. Review the generated preview address and select Create site. Most sites need no other fields.

If the setup check needs help, it explains the next action. A Next.js website must have output: "export" in its Next config (official static-export instructions); server-rendered sites need a different runtime. Commit that change in the source, then select Detect settings again. The panel reads source files to suggest settings; it does not execute a build during this check.

3. Build, publish the preview and review it

1. Select Build latest version. Wait until the version says Ready to publish. Use Build details to inspect a failed build.
2. Select Publish on the intended version. Confirm the site and commit in the dialog. It then says Live now.
3. Select Open preview. Review the actual published preview, not just the editor's local preview.

Before connecting a client domain

• Open every public page directly and follow the navigation, footer links and buttons. Check links do not lead to an editor preview or old host.
• Check mobile and desktop layouts, images, videos, fonts and deep links. Refresh an inner page to test its routing.
• Confirm contact details and client-approved content. Remove demonstration copy and placeholder links before a real launch.
• Inspect the browser console/network for failures and missing assets. Test the site on a fresh session and a phone.
• Verify real forms and their destination using agreed test data. Confirm CRM receipt with the team. A static contact form must use an approved external form endpoint.
• Verify checkout destinations and appointment widgets. Use an agreed test-payment mode or manual handoff rather than submitting a live charge as a routine website check.
• Check title, description, favicon, canonical URLs and the sitemap. Apply an agreed indexing policy: demonstrations and staging sites should remain excluded from search; real public launches should use the intended production URLs.

A failed build leaves the published version in place. A source commit reaches visitors after you build and publish the resulting release.

4. Connect the customer's domain

First confirm the customer has approved the website and you have permission to manage their DNS. You or the customer's domain administrator needs access to the actual DNS provider. The domain can stay registered where it is.

1. After publishing the preview, open the project and select Connect domain. Enter only the domain, for example example.com.au. Enable the www option if both root and www should work. The root becomes the canonical address; www redirects to it.
2. Select Show DNS instructions. The panel generates the records for this specific project. Use those values, not values copied from another client.
3. At the DNS provider, add only the records under 1. Ownership and HTTPS: the ownership TXT and the HTTPS validation CNAMEs. These can be added while the existing website remains live.
4. Keep validation CNAMEs DNS-only if the provider is Cloudflare. Select Verify ownership & prepare HTTPS. The panel checks public DNS, then prepares the certificate and routing. Keep the tab open or return later to check progress.
5. When the panel says HTTPS ready — connect the website, update only the records under DNS details → 2. Website connection records. Replace conflicting website A/AAAA/CNAME records for those exact names. Preserve MX, SPF, DKIM, DMARC and unrelated records.
6. Keep website records DNS-only during the connection check. Select Check website connection. When it says Connected, open the customer site and repeat the launch checks on that domain.

Once connected, the panel shows the domain and Open website. DNS records are tucked under DNS details so daily updates stay simple. Use Domain options for disconnection.

Entering DNS names

The panel displays full DNS names. Some providers accept them directly; others ask for the name relative to the zone. For the zone example.com.au, the root name is @, www.example.com.au becomes www, and _reviewfy-deploy.example.com.au becomes _reviewfy-deploy. A website at shop.example.com.au uses shop, _reviewfy-deploy.shop and _acme-challenge.shop.

Use the panel's exact values and a reasonable DNS TTL such as 600 seconds. Record propagation varies by provider and previous TTL. Remove a conflicting AAAA record if the panel's connection instructions provide only an A record.

Keep the ownership TXT and HTTPS validation CNAMEs for ongoing verification and automatic renewal. If an HTTPS validation record already exists for another active service, involve the administrator before replacing it. Check that existing CAA records permit letsencrypt.org.

For a client who wants Cloudflare caching, ask the administrator to configure and verify it after the DNS-only launch. The connection checker currently verifies direct origin DNS; the separate public Reviewfy website has its own CDN configuration.

The panel prepares hosting and HTTPS. It does not log in to the customer's registrar, buy a domain, replace the full DNS zone, or change their email setup.

5. Update or restore a website

1. Edit the source in the cloud editor or GitHub and commit/push to the configured branch.
2. Select Build latest version. Check the new commit and use Build details if you need its output.
3. Publish the ready release and inspect the preview and customer domain. They both use the project's published version.
4. If the change causes a problem, select Restore this version on a version marked Previously live, then confirm Restore version. This restores its files without rerunning the build.

After a rollback, correct the source before publishing another build. A rollback restores hosting content; it does not undo form submissions, payments or other external effects.

Disconnect domain stops that domain serving the project. It keeps the domain association and DNS instructions so you can select Reconnect domain and verify it again. Ask the administrator to move a domain to a different project.

Troubleshooting