Project Settings

Project Settings controls application-wide publishing, identity, appearance, authentication, Code, and advanced behavior.

These settings provide defaults and shared configuration for the Project. Individual Pages can override some presentation settings, such as fonts and theme color, through Page Settings.

Opening Project Settings

To open Project Settings:

1. Open the Project in the Project Editor.
2. Select Settings.
3. Select Project Settings.

The settings are organized into the following sections:

• Publishing
• General
• Fonts
• Authentication
• Code
• Advanced

Select Save after changing the settings. Saving records the development configuration; changes that affect published pages or addresses require the Project to be published again.

Publishing

The Publishing section controls whether the published Project is available, which Page opens first, and the addresses through which users reach it.

Publish Status

Publish Status controls the availability of the published Project.

Use the disabled state when the published application should not be available. Disabling a Project affects its published availability; it does not delete the Project or its development configuration.

Before disabling a live Project, consider active users, integrations, Web Hooks, and any external systems that depend on its published address.

Starting Page

Starting Page identifies the Page opened at the Project's root published URL.

Choose a Page that provides the intended entry experience, such as a landing page, sign-in destination, or application dashboard.

The selected Page must be included in a successful publish before users can rely on it as the published starting page. After changing the Starting Page, republish and test the root URL.

Project URL

The Project URL is the ioLoop-hosted address assigned to the published application. Available URL options depend on the Project's subscription and publishing entitlements.

Important: Saving a new or changed Project URL does not make that address active by itself. You must publish the Project for the URL change to take effect.

When changing the Project URL:

1. Select or enter an available URL using the controls shown in Project Settings.
2. Save the change.
3. Publish the Project.
4. Test the new address.
5. Update bookmarks, links, Web Hook callers, OAuth settings, and external references as needed.

Removing a configured URL can also make the published Project unavailable. Review the confirmation shown by the Project Editor before continuing.

After adding, changing, or removing a Project URL, complete a successful publish and verify the address before sharing it with users.

Custom Domain

A supported subscription can publish the Project through a custom domain, such as app.example.com.

Important: Saving a Custom Domain does not make it active by itself. You must publish the Project after adding, changing, or removing a Custom Domain.

ioLoop supports non-apex domains only. A non-apex domain includes a hostname before the registered domain. The bare or root domain is the apex domain and cannot be used directly as the Project's Custom Domain.

Domain	Supported?	Explanation
app.example.com	Yes	Uses app as a hostname.
portal.example.com	Yes	Uses portal as a hostname.
www.example.com	Yes	Uses www as a hostname.
customers.us.example.com	Yes	Uses a multi-level hostname.
example.com	No	This is the apex domain.
example.co.uk	No	This is the apex domain for the registered domain.

Choose a hostname that represents the application, such as app, portal, or www. If users also need to enter the apex domain, configure an appropriate redirect with the DNS or domain provider to send them to the supported non-apex Custom Domain.

To configure a custom domain:

1. Configure or select the Project URL required by the editor.
2. Enter the custom domain.
3. Review the DNS information displayed by the Project Editor.
4. Create the required CNAME record with the DNS provider.
5. Save Project Settings.
6. Publish the Project.
7. Allow time for DNS detection and HTTPS provisioning.
8. Test the custom domain over HTTPS.

DNS propagation, validation, and certificate provisioning can take time. A saved custom domain is not necessarily ready immediately.

The domain becomes available only after the Project is published, the required DNS record is detected, and HTTPS provisioning completes.

When replacing or removing a domain, update external references and provider configuration that use the previous address. This can include OAuth redirect URLs, embedded links, Web Hook destinations, Open Graph URLs, and email templates.

General

The General section contains Project identity and presentation information.

Setting	Purpose
Display Name	User-facing name used by supported application and authentication experiences.
Description	Description of the Project.
Developer	Person or organization responsible for the application.
Version	Application version information maintained by the Project team.
Copyright	Copyright notice associated with the Project.
Logo	Logo used by supported authentication and application experiences.
Project Theme Color	Project-wide default theme color used when a Page does not provide its own value.

Display Name and Logo

Use a Display Name and logo that users will recognize when signing in, resetting a password, or encountering another supported application screen.

The Logo value must point to an image that intended users can load. You can enter a URL or browse the Project's Media. If the image requires authentication, blocks external access, is deleted, or is moved, it may not appear.

After changing application identity:

• Test sign-in and password-reset screens.
• Republish if the change must appear in published Page content.
• Verify the result on both desktop and mobile layouts.

Project Theme Color

Project Theme Color provides a Project-wide default for supporting browser and Page behavior. A Page-specific theme color takes precedence when configured.

Project Theme Color is not a replacement for the colors used by Page Elements or custom CSS. Republish the Project after changing it.

Fonts

The Fonts section defines the Project-wide font collection and default heading and body fonts.

Font List

The Font List determines which supported fonts are available for Project-level and Page-level selection.

When adding fonts, consider:

• Readability at small and large sizes.
• The styles and weights required by the design.
• Loading performance when many font families or variants are included.
• Language and character support.

Heading and Body Fonts

Heading Font is the default for headings. Body Font is the default for general text.

Pages can provide their own font choices. A Page-level choice overrides the corresponding Project default for that Page.

Republish after changing Project fonts. Then review representative Pages to confirm that text remains readable and layouts have not shifted unexpectedly.

Authentication

The Authentication section configures CAPTCHA protection for supported sign-in and account-recovery actions.

Setting	Purpose
Use Captcha for Authentication	Enables CAPTCHA for supported authentication requests.
Captcha Server Key	Private key used to validate CAPTCHA responses.
Captcha Client Key	Public key used by the browser to present the CAPTCHA challenge.

The two keys must belong to the same CAPTCHA configuration and must be valid for the Project's published domains.

To enable CAPTCHA safely:

1. Create or select the CAPTCHA configuration with the provider.
2. Add every intended Project URL and custom domain to the provider configuration.
3. Enter the client and server keys in Project Settings.
4. Enable CAPTCHA.
5. Save the settings.
6. Test sign-in and password recovery through each published domain.

Treat the server key as a secret. Do not place it in Page content, client-side Code, screenshots, or public support material.

If CAPTCHA is enabled with incorrect keys or domain restrictions, users may be unable to authenticate. Keep an authorized Creator session available while testing the change.

Code

The Code section includes existing JavaScript and CSS files at the Project level.

Project-level Code is appropriate for assets intended to be available broadly, such as:

• Shared brand styles.
• Common browser-side utilities.
• Formatting helpers used by several Pages.
• CSS for repeated application patterns.

The list includes Code files that already exist under Frontend → Code. Adding a file here includes it in the Project; it does not create the file.

Order matters when one JavaScript file depends on another or when CSS rules compete. Arrange dependencies before the files that use them, and test the resulting load order.

Use Page-level Code when an asset is needed only by one Page or Form. Broad inclusion increases the number of Pages affected by a code change and can introduce naming or styling conflicts.

Republish after adding, removing, or reordering Project-level Code. For creating and maintaining the files themselves, see Code.

Advanced

Advanced settings affect published application behavior across multiple Pages. Test them carefully before publishing.

Hide Built on ioLoop

Supported paid plans can hide the Built on ioLoop banner.

The subscription must provide this capability. Saving the setting does not add the entitlement to an ineligible Project. Republish after changing the setting.

Default Timezone

Default Timezone establishes the Project-wide timezone used by supported client-side date and time behavior.

Choose the timezone that represents the application's business rules, not necessarily the current Creator's location. Consider daylight-saving changes and users in other regions.

Custom code can still parse, convert, or display times differently. Test date boundaries, scheduled events, and daylight-saving transitions. Republish after changing the default.

HTML Head Additions

Select Edit next to HTML Head Additions (Project Level) to open the editor.

This setting adds custom content to the HTML <head> section of every published Page and Form in the Project.

Common uses include:

• Additional Project-wide metadata.
• Site-verification tags.
• Links to external stylesheets.
• Supported external scripts and third-party browser libraries.
• Integrations that require supported HTML head markup on every Page.

For example, an external stylesheet can be referenced using:

<link rel="stylesheet" href="https://example.com/styles.css">

Use Project-level HTML Head Additions when the same head content is required throughout the application. If the content is needed by only one Page or Form, use its Page-level HTML Head Additions instead.

Avoid duplicate or conflicting metadata when an equivalent Project or Page setting already exists. Invalid or conflicting markup can affect every Page.

For JavaScript and CSS assets managed within ioLoop, prefer using Frontend Code when appropriate. For a broader explanation of head additions in custom frontend development, see Standards-Based Frontend.

Do not use HTML Head to expose secrets. Third-party scripts can observe Page content and user activity, so review their privacy and security impact before inclusion.

Custom Style Definitions

Select Edit next to Custom Style definitions (Project Level) to open the CSS editor.

This setting defines CSS that applies throughout the published Project.

For example:

.project-highlight {
  background-color: #f5f7fa;
  border-radius: 8px;
  padding: 16px;
}

These styles can be used by matching elements across Pages and Forms, allowing consistent presentation beyond the visual editor's standard options.

Use it for concise global overrides that cannot be expressed clearly through standard design settings. Prefer reusable CSS Code files when styles are substantial or require clearer maintenance and versioning.

If CSS is required by only one Page or Form, use its Page-level Custom Style Definitions instead.

Consider selector specificity and conflicts with styles defined by individual Pages or included Code assets. Broad selectors can unintentionally change Pages, Forms, Widgets, shared components, and responsive layouts. Test representative Page types and screen sizes after making a change.

Republish after changing HTML Head Additions or Custom Style definitions.

When to Republish

Use this table when planning a Project Settings change:

Change	Save	Republish
Publish Status	Required	Not normally required only to disable an existing published Project.
Starting Page	Required	Recommended and required when the selected Page is not in the current published version.
Project URL or custom domain	Required	Required.
Display Name, Logo, or CAPTCHA	Required	Republish when the change must also appear in published Page content.
Description, Developer, Version, or Copyright	Required	Republish if a Project component uses the changed metadata.
Theme Color or Fonts	Required	Required.
Project-level Code	Required	Required.
Hide Built on ioLoop	Required	Required.
Default Timezone	Required	Required.
HTML Head Additions or Custom Style definitions	Required	Required.

After publishing, test both the root URL and direct Page URLs. Include a signed-out test when authentication settings changed.

Good Practices

• Make related Project Settings changes together, then perform one complete Preview and publish review.
• Use Page-level overrides only when a Page intentionally differs from the Project default.
• Keep global Code, HTML Head Additions, and Custom Style definitions small and well documented.
• Test domain and authentication changes before announcing a new address.
• Maintain external provider settings whenever the Project domain changes.
• Verify representative Pages after changing fonts, CSS, theme color, timezone, or shared Code.

Common Mistakes

Avoid these patterns:

• Saving a domain or presentation change without republishing.
• Selecting a Starting Page that has not been successfully published.
• Assuming a Page-specific setting cannot override a Project default.
• Adding a CAPTCHA key that is not authorized for every published domain.
• Treating the CAPTCHA server key as public configuration.
• Including Project-level Code when only one Page needs it.
• Adding broad CSS without testing Forms, Widgets, and responsive layouts.
• Placing secrets or trusted authorization logic in HTML Head or client-side JavaScript.

Related Topics

• Settings
• Page Settings
• Code
• Previewing
• Project Lifecycle
• Publish Project