ioLoop Docs

Appearance

Publish Project ​

Publish Project releases the Project's latest saved and publishable development state to its users.

Use Publish Project for the first release and whenever saved development changes must replace the current published version. Publishing is a deliberate operation: saving, Previewing, and testing do not update the live application by themselves.

Publishing requires Creator access that includes permission to publish the Project. Project Users who sign in to the application do not receive Project Editor or publishing access through their user accounts. For Creator permissions, see Creators.

Before Publishing ​

Treat publishing as a release of the complete application. A Page that works in isolation can still depend on Database structure, Cloud Flow, Connections, AI Agents, Project Settings, or access rules that also need to be ready.

Save and Test the Development Version ​

Before publishing:

  1. Save all affected Pages, Forms, Page Flow, Code files, and settings.
  2. Save changed Database, Cloud Flow, Connection, and AI Agent configuration.
  3. Preview the affected Pages and Forms.
  4. Test both successful and failed operations.
  5. Test with representative public, signed-in, group-specific, and administrator contexts.
  6. Review external-service side effects and confirm the intended test or live provider environment.
  7. Review production-data effects from table-definition changes.

Publish uses saved development state. A change that remains unsaved in an editor is not ready to be released.

Configure an Active Starting Page ​

A Starting Page is required before publishing. It is the Page that opens at the root Project address.

To review it:

  1. Open Settings → Project Settings.
  2. Expand Publishing.
  3. Select the intended Starting Page.
  4. Save Project Settings.
  5. Confirm that the selected Page is active and works in Preview.

If no Starting Page is configured, Publish Project stops and directs you to Project Settings.

An inactive Starting Page is not included among the active Pages released by publishing. Verify the root address after every Starting Page change.

Review Project Users and Protected Resources ​

Before the release, ioLoop reviews the access configuration of Pages, Database tables, and Connections.

If one or more of these resources requires authenticated access but the Project has no Project Users, publishing is stopped. Add at least one appropriate Project User under Settings → Users, then test the protected experience before publishing again.

Adding a user is only one part of access configuration. Also verify:

  • The user's status and credentials.
  • User Group membership and role levels.
  • Page and Form access.
  • Database operation access.
  • Connection and Cloud Flow access.
  • Authorization enforced by trusted Backend workflows.

For details, see Users and User Groups.

Review Addresses and Domains ​

The Project can use its assigned ioLoop address, a configured Project URL, or a supported custom domain.

Project URL and Custom Domain changes do not become active merely because they were saved. A successful Project publish is required.

If the Project uses a custom domain:

  • Use a non-apex domain such as app.example.com, portal.example.com, or www.example.com.
  • Do not use an apex domain such as example.com directly.
  • Create the DNS record shown in Project Settings.
  • Allow time for DNS validation and HTTPS provisioning.
  • Keep the existing address available until the new domain has been verified, where practical.

For the complete configuration workflow, see Project Settings — Custom Domain.

Plan for Temporary Unavailability ​

Starting a publish temporarily makes the published Project inaccessible. The new published version is activated only after the publishing process completes.

Before publishing an application already in use:

  • Choose an appropriate release time.
  • Account for active users and in-progress Forms.
  • Consider external systems calling published Web Hooks.
  • Avoid starting another release while a publish is in progress.
  • Be prepared to verify the application immediately afterward.

Development and Preview activity do not normally interrupt the published application. The interruption begins when the publish itself starts.

Publishing the Project ​

To publish:

  1. Open the Project in the Project Editor.
  2. Select Publish.
  3. Select Publish Project.
  4. Review the warning that the Project will be inaccessible during publishing.
  5. Select Start.
  6. Keep the publishing window open while progress is displayed.
  7. Wait for Published Successfully before treating the release as complete.

During publishing, ioLoop prepares the active Pages and Forms, applies applicable Project and Backend changes, updates the published address configuration, and activates the released application.

The duration depends in part on the number and complexity of the Pages and Forms being published. Do not assume the release completed because an older browser tab still displays content.

Active and Deactivated Pages ​

Publishing includes active Pages and Forms. Deactivated Pages and Forms are not included in the new published version.

This means that after publishing:

  • A newly activated Page can become available.
  • Changes to an active Page replace its previous published version.
  • A deactivated Page that existed in the previous release becomes unavailable.
  • A deleted Page remains unavailable and references to it may fail.

Review menus, Buttons, Page Flow navigation, external bookmarks, and direct links when a Page URL changes or a Page is deactivated or deleted.

Database Effects ​

The development and production environments keep separate application records. Publishing updates the production application configuration and can apply Database structure changes.

Table Structure ​

Publishing can apply changes such as:

  • Creating a production table corresponding to a development table.
  • Adding a field to existing production records.
  • Removing a field from existing production records.
  • Converting existing field values after a field-type change.
  • Updating named queries and table access configuration.

Field removal and type conversion can change or remove production values. Review these operations before publishing and verify representative production records afterward.

Development Records ​

Publishing does not merge development records into a production table that already contains records.

If the corresponding production table is empty, the development records for that table are copied into it during publishing. Once the production table contains records, a later publish does not add, merge, or overwrite its records with development records.

Evaluate this rule separately for each table. For example, publishing may leave records in a populated Customers production table unchanged while copying development records into an empty Categories production table.

Do not place test data in development with the assumption that publishing will always ignore it. Before the first production use of a table, review its development records and remove samples that should not be copied.

For complete guidance, see Development and Production Data and Table Fields.

The Publish Report ​

After a successful publish, the result includes a report for:

  • Pages.
  • Data Tables.
  • Connections.

The summary shows the total number of resources reviewed and how many are password protected or open to the public. Expand the report to inspect the named resources in each category.

Use the report as a release review:

  1. Look for a resource that is unexpectedly public.
  2. Look for a resource that is unexpectedly password protected.
  3. Return to the corresponding access settings if the classification is not intended.
  4. Correct and test the access configuration.
  5. Publish again.

The report is not a substitute for authorization testing. A Page can be protected while its underlying table, Connection, Web Hook, or other operation remains more broadly accessible. Test the protected operation itself, including denied cases.

If Publishing Fails ​

A publish can stop because of a missing Starting Page, missing Project Users for protected resources, a Page that cannot be prepared, a Database change that cannot be applied, a domain problem, or another release error.

Because the current published Project is taken offline at the start of the operation, a failed publish may leave it inaccessible.

If publishing fails:

  1. Read the error shown in the publishing window.
  2. Note the Page or area being processed when the failure occurred.
  3. Correct the development configuration or temporary service problem.
  4. Save and retest the affected component.
  5. Run Publish Project again.
  6. Wait for Published Successfully.
  7. Launch and verify the Project.

Do not assume that the previous published version was automatically restored. Check the actual published address.

If a Page fails while publishing, test that Page in Preview and review its referenced Forms, Page Slices, Code assets, Widgets, Page Flow, and other dependencies.

After Publishing ​

Select Publish → Launch Project and verify the released application.

At minimum, check:

  • The root URL opens the intended Starting Page.
  • Direct Page URLs and application navigation work.
  • Deactivated or removed Pages are unavailable as intended.
  • Public and authenticated access behave correctly.
  • Representative User Groups receive the intended access.
  • Forms validate, submit, and report failures correctly.
  • Database operations use and preserve the expected production records.
  • Published Cloud Flow and Web Hook entry points work.
  • Connections use the intended live provider accounts and credentials.
  • AI Agent interactions work with published dependencies.
  • Media, JavaScript, CSS, and external resources load successfully.
  • The custom domain works over HTTPS, when configured.

Review live Cloud Flow logs when a Backend operation does not behave as expected. A successful publish confirms that the release operation completed; it does not prove that every business workflow or external provider will return the intended result.

Good Practices ​

  • Publish a tested collection of related changes rather than unrelated unfinished work.
  • Review production schema effects before releasing Database changes.
  • Remove development sample records before publishing an empty production table when those records must not become live data.
  • Schedule publishing with its temporary interruption in mind.
  • Keep a short release checklist for important user and administrator workflows.
  • Review the public and password-protected resource report after every release.
  • Verify the published application immediately after publishing.
  • Keep external callers and provider configuration updated when addresses change.

Common Mistakes ​

Avoid these patterns:

  • Assuming Save or Preview updates the published application.
  • Publishing with unsaved changes still open in an editor.
  • Selecting an inactive or untested Starting Page.
  • Publishing protected resources before creating and testing an appropriate Project User.
  • Treating the publish report as proof that every underlying operation is secure.
  • Assuming development records will merge into populated production tables.
  • Forgetting that development records are copied when their corresponding production table is empty.
  • Removing or retyping a field without reviewing existing production values.
  • Saving a Project URL or custom domain without publishing afterward.
  • Closing the release process before confirming Published Successfully.
  • Assuming a failed publish automatically restores the earlier published version.
  • Skipping post-publish verification because Preview succeeded.