Launch Project

Launch Project opens the published application through its configured address.

Use Launch Project after publishing to verify the released user experience. Launching does not publish development changes, restart a failed release, or confirm that every application workflow is functioning correctly.

Before Launching

The Project must have completed a successful publish. If it is not currently published, Launch Project displays a message directing you to publish it first.

Before launching, confirm that:

• Publish Project reported Published Successfully.
• The intended Starting Page was active and included in the release.
• Project URL or custom-domain changes were included in that successful publish.
• Any required DNS record has been created for a custom domain.

Opening the Published Project

To launch:

1. Open the Project in the Project Editor.
2. Select Publish.
3. Select Launch Project.
4. Use the opened application to test the released experience.

Launch Project chooses the published address in this order:

1. The configured Custom Domain, when one is saved.
2. The configured Project URL.
3. The Project's assigned default published address.

The application opens over HTTPS.

Project URL and Custom Domain Changes

Saving a Project URL or Custom Domain does not activate that address. You must publish the Project after adding, changing, or removing either setting.

For custom domains, ioLoop supports non-apex domains such as:

• app.example.com
• portal.example.com
• www.example.com
• customers.us.example.com

Apex domains such as example.com or example.co.uk cannot be used directly as the Project's Custom Domain.

After publishing, DNS validation and HTTPS provisioning may still take time. Launch Project can open the configured custom domain before that external setup has completed, so an error immediately after publishing does not necessarily mean that the Project itself failed to publish.

If the custom domain is not ready:

1. Confirm that the required CNAME record matches the value shown in Project Settings.
2. Check for conflicting DNS records on the same hostname.
3. Allow time for DNS changes and HTTPS provisioning.
4. Try the address again over HTTPS.

For complete setup instructions, see Project Settings — Custom Domain.

What to Verify After Launching

Launch the application as a release verification step, not only as a visual review.

Address and Navigation

Verify that:

• The root address opens the intended Starting Page.
• Menus, Links, Buttons, and Page Flow navigation use the correct published URLs.
• Direct links to important Pages work.
• Deactivated and removed Pages are unavailable as intended.
• Redirects and external links use the current Project address.

Public and Authenticated Access

Test from a signed-out browser session as well as appropriate signed-in sessions.

Check:

• Public Pages open without an unintended sign-in requirement.
• Protected Pages direct signed-out visitors through the intended authentication experience.
• Project Users can sign in and sign out.
• Representative User Groups can access permitted resources.
• Restricted Pages and operations deny users who should not have access.
• Administrator behavior is not being used as the only access test.

Hiding a navigation item is not an authorization test. Attempt the protected Page, Database operation, Connection, or Web Hook through its actual published interface.

Forms and Production Data

Use production-safe values when testing a published Form or workflow.

Confirm that:

• Required-field and validation behavior is correct.
• Successful submissions create or update the intended production records.
• Errors are understandable and do not expose sensitive details.
• Empty, missing, and duplicate input is handled appropriately.
• Published queries return the intended production results.
• Table-structure changes preserved or converted existing production values as expected.

Published application operations use production data. Results can differ from Preview because Preview's built-in Database operations use development records.

Backend and External Services

Verify representative released operations involving:

• Cloud Flow Web Hooks and other published entry points.
• Background Tasks where their timing and side effects are relevant.
• Connections and external service accounts.
• Payment, messaging, email, or other provider modes.
• AI Agents and their published Knowledge Sources or functions.
• Live Cloud Flow logs.

Preview success does not prove that production records, live provider credentials, published URLs, or external account restrictions are correct.

Presentation and Browser Behavior

Check representative desktop and mobile devices or browser sizes for:

• Layout and navigation.
• Fonts, theme color, and shared CSS.
• JavaScript behavior and browser-console errors.
• Images, videos, PDFs, and other Media.
• Sign-in, password recovery, and CAPTCHA behavior.
• Social sharing metadata where applicable.

Launch Is Not a Health Check

Launch Project opens the configured published address. It does not automatically verify:

• That every Page or direct URL works.
• That the current user has the intended permissions.
• That production data is complete or correct.
• That a Web Hook caller uses the right endpoint.
• That an external Connection is authorized.
• That a custom domain has completed DNS and HTTPS setup.
• That Background Tasks or AI Agent operations succeed.

Use the application itself, representative accounts, provider dashboards where appropriate, and live logs to complete verification.

Troubleshooting

Problem	What to Check
Project must be published first	Complete Publish Project successfully, then launch again.
Root address returns a missing Page	Starting Page selection, whether the Page is active, and whether the latest publish succeeded.
Custom domain does not open	Successful publish after saving the domain, CNAME value, DNS propagation, and HTTPS provisioning.
Old address or content appears	Latest successful publish, browser cache, saved Project URL, and external links or redirects.
Direct Page URL fails	Page Active setting, Page URL, latest publish, and access configuration.
User is redirected to sign in	Page access, user status, credentials, User Group membership, and current session.
Preview works but Launch fails	Production records, published configuration, live Connections, published URLs, access rules, and live logs.
Image, CSS, or JavaScript is missing	Published Page references, included Code assets, Media URLs, browser errors, and the latest successful publish.
Web Hook or external caller fails	Published endpoint, HTTP method, authentication, Access settings, caller configuration, and live logs.

Good Practices

• Launch immediately after every publish.
• Test in a private or signed-out browser session for public and authentication behavior.
• Use representative non-administrator Project Users.
• Test denied operations as well as successful ones.
• Use production-safe test records and clean them up when appropriate.
• Verify custom domains over HTTPS before announcing them.
• Update bookmarks, OAuth redirect URLs, Web Hook callers, and external references after an address change.
• Record and investigate live errors before beginning unrelated development changes.

Common Mistakes

Avoid these patterns:

• Treating Launch Project as a substitute for Publish Project.
• Expecting saved development changes to appear without a successful publish.
• Assuming that opening the Starting Page proves the complete application works.
• Testing only while signed in as an administrator.
• Reusing Preview test data assumptions in the production application.
• Assuming a custom domain is ready immediately after it is saved or published.
• Sharing a new address before testing HTTPS and important direct links.
• Ignoring live logs when a published Backend workflow fails.

Related Topics

• Publish
• Publish Project
• Project Settings
• Previewing
• Users
• User Groups
• Development and Production Data
• Web Hooks
• Testing and Logs