CU Launch User Guide

This guide explains the complete app lifecycle in plain language. Start with the Quick Start if you only need the shortest path to a first published app.

1. What the portal does

CU Launch brings the main pieces of an app into one managed workflow. It can create starter code from an approved template, keep that code in a managed GitHub repository, prepare Azure hosting, publish the app, and help you manage access afterward.

The portal does not design every screen or write every business rule for you. After creating the starter, you can work with Codex or a developer to customize the app. GitHub remains the supported source of truth: the version stored there is the version Cedarville tools review and publish.

2. Understand the app lifecycle

1. Launch or add: Select Launch New App for a template or Add Existing App for code that already exists.
2. Customize: Use Codex or a developer to change the managed GitHub repository.
3. Prepare: The portal adds and checks the settings needed for GitHub and Azure to work together.
4. Publish: The portal starts the GitHub workflow that sends the current app to Azure.
5. Manage: Before the first successful publish, use Continue Setup. After success, use Manage App for the full details and management controls.

3. Choose the right starting point

Launch New App

Choose Launch New App when you are starting a new project and want Cedarville-approved defaults. The entry page first explains that choosing a template is the next step. Recommended Templates are written for common, non-technical use cases. Developer Starters expose lower-level choices and are better when a developer already knows the intended architecture.

Common template choices include:

• A PostgreSQL database for information the app must save.
• An audience choice: require Cedarville sign-in or make the app openly public.
• A web interface for forms, trackers, and information pages.
• An API or automation service for a system-to-system process without a normal web page.

Choose only the options your app needs. The portal no longer asks you to choose a runtime; it prepares that technical detail for you.

Add Existing App

Choose Add Existing App when code already exists.

• Already on GitHub: Give the portal the repository address. If necessary, the portal imports it into Cedarville's managed GitHub organization while preserving its history. The portal checks whether it matches a supported Azure App Service runtime.
• Only on my computer: Let the portal create an empty managed repository. The focused wizard provides a prompt that makes Codex responsible for checking the folder, protecting secrets, preserving existing change history, connecting the managed repository, and uploading the code.

Imported apps currently support root Next.js, Express, Python FastAPI, and plain static Python apps. A repository with conflicting publishing files may require a GitHub review page before the portal applies its setup.

4. Launch and choose what happens next

1. From the home page, select Launch New App and then Choose an app template.
2. Read the template summaries and select the closest match.
3. Enter a short, recognizable app name. Avoid department abbreviations that coworkers may not understand.
4. Describe the app's purpose and intended users.
5. Choose who can use the app:
   • Cedarville sign-in required means users must sign in with a Cedarville account.
   • Openly public on the internet means anyone who knows or discovers the app address can use it. Read and confirm the warning before choosing this option.
6. Review the optional database choice.
7. Select Launch App. Creation stops before publishing.

When Your starter app is ready appears, choose Publish the starter now or Customize it with Codex first.

Publish the starter now starts Azure publishing immediately. It is the only publish confirmation for an unchanged starter and does not require your own GitHub account. Customize it with Codex first starts the GitHub access and Codex handoff steps. Codex is optional; after customized code is pushed and setup is ready, that path later presents Publish to Azure.

5. GitHub access and Codex customization

GitHub is the managed online location for the app's code. It records changes and lets Cedarville's publishing workflow use a reviewed source.

Git is the tool that keeps change history in the app folder on your computer. Before opening a Codex handoff:

1. On Windows, open Company Portal, search for Git, and select Install. On macOS, open CedarNet 2.0, search for Git, and select Install.
2. When installation finishes, completely quit and reopen Codex.
3. Make a new empty folder named for a generated app. For an app already on your computer, keep using the folder that already contains it.
4. In Codex, open Projects and create a local Codex project using that folder. Make it the primary folder, which tells Codex where the app's files belong.
5. Open that project and start the task inside it. Do not use Quick chat or start a standalone task outside the project.
6. Paste the portal's complete prompt into that project task. Codex checks the folder and Git before changing anything.

If you choose customization, the wizard asks whether you already have a GitHub account. A GitHub account is a login for the website where the app's private code home is stored. To continue:

1. If you need an account, open the supplied GitHub signup link. Choose a GitHub username during signup, complete GitHub's verification, sign in, and return to the same portal tab.
2. Enter the username you chose and select Send repository invite. The username is not your email address or display name. You can find it after github.com/ in your GitHub profile address.
3. Accept the private repository invitation on GitHub.
4. Return and select I've accepted the invitation.
5. Follow the Before opening Codex checklist, then copy the complete prompt into the task inside the app's local Codex project. Let Codex inspect, change, test, commit, and push the app.
6. Return only after Codex reports that the push succeeded.

Portal collaboration and GitHub access are separate. Confirm that finished changes are committed and pushed to the managed repository; the portal cannot publish local files that were never pushed. Codex uses an HTTPS repository address and may open a secure browser or operating-system GitHub sign-in. Complete that sign-in yourself. Never provide a GitHub password, personal access token, SSH key, or other secret. Codex should stop and direct you to Cedarville IT if secure sign-in does not work; it should not use the GitHub plugin or GitHub CLI as a fallback.

Permission prompts

Codex may ask to use the app folder, run a normal development command, or open secure GitHub sign-in. Read each request and allow only what is needed for the current app task. If a prompt offers Allow once, choose that option unless Cedarville IT has approved an established workflow that needs broader access.

It is normally appropriate to allow access to the app folder you selected and to complete secure browser sign-in yourself. Do not approve access to unrelated folders or applications, and never paste passwords, tokens, private keys, or portal credentials into Codex.

6. Add code that already exists

Already on GitHub

Paste the repository's web address and give the app a recognizable name. The portal makes or reuses the managed Cedarville copy, preserves the source history, and checks whether it matches a supported Azure runtime. It supports root Next.js, Express, Python FastAPI, and plain static Python apps.

Select Prepare my app for publishing when offered. The portal adds only the publishing files the app needs. If existing files conflict, it does not overwrite them. Select Open a safe review on GitHub to create a pull request, which is a GitHub page showing proposed changes. Review and merge it, then select I've approved the changes so the portal can verify them.

Only on my computer

Enter the local app name and select Create online home. Follow the GitHub account or invitation steps if shown. Create a local Codex project from the folder that already contains the app, make that folder primary, and start the task inside the project, not Quick chat. Copy the local-upload prompt into that task. Codex preserves your history, connects the managed repository, and pulls the portal's app guidance before changing anything. It then checks whether the app already uses a supported type. If not, it explains and performs the smallest safe migration to Next.js, Express, FastAPI, or a plain static app while preserving the app's behavior. Codex tests the result before pushing it. Select My code has been uploaded only after Codex reports success.

The portal then scans and prepares the uploaded code. If the runtime is unsupported, it returns a repair prompt to Codex. After Codex repairs, tests, and uploads the app, select I've repaired and uploaded my code. Do not use either confirmation before the upload succeeds.

7. Publishing to Azure

Publishing makes the current GitHub version available as a running website in Azure.

Before publishing, confirm:

• Repository status is ready.
• Publishing setup is ready.
• Required environment variables have been added.
• The code you want is present in the managed GitHub repository.

For a customized generated app or an imported or local app, select Publish to Azure from the focused wizard after preparation and setup are ready. This separate button is the explicit confirmation for those paths; setup and repair never publish on their own. An unchanged generated starter does not show a second confirmation because Publish the starter now already starts publishing. Publishing may take several minutes. Preparation, setup checks, repairs, and publishing pages refresh automatically, so leave the page open and do not repeat an action while it is running.

When publishing succeeds, the wizard shows Your app is online, Open your app, and Open app details. Open the app first to check its main task. The details page includes a plain-language readiness summary; technical management controls are under Advanced options. If you leave earlier, My Apps shows Continue Setup and resumes the exact safe step. After success, My Apps shows Manage App.

Share in Portal is separate from app access. It lets signed-in Cedarville portal users discover the app's name, description, and link. It does not make an app public or change the audience you chose at creation.

After publishing, open the app and test its most important task. A successful deployment only proves that Azure started the app; it does not prove every form, permission, integration, or data rule behaves correctly.

Updating an app

1. Make and test the change with Codex or a developer.
2. Push the change to the managed GitHub repository.
3. If push-to-deploy is enabled, the GitHub workflow may publish automatically. Otherwise, return through Manage App and select Publish to Azure.
4. Test the published app again.

8. Environment variables and secrets

Environment variables provide settings the app needs at runtime, such as an external service address or secret credential. Add them from the app details page instead of placing secret values in the code or documentation.

The portal stores user-managed secret values in an app-specific Azure Key Vault and gives only that app access. The portal does not show the secret value again after it is saved.

Good practices:

• Use the exact variable name provided by the app or integration instructions.
• Paste only the value, without explanatory text.
• Replace a variable when its credential rotates.
• Republish or restart as directed after changing a required setting.
• Never put real secrets in GitHub files, screenshots, support tickets, or email.

9. Collaborators and ownership

Every app has one primary owner. Owners and administrators can invite Cedarville coworkers by email. The coworker must accept the invitation through Cedarville sign-in before becoming a collaborator.

Collaborators can view app details, request their own GitHub access, repair publishing setup, and publish changes. They cannot delete app resources or transfer ownership. An administrator can reassign the primary owner when responsibility changes.

Removing a collaborator ends portal access immediately. GitHub access is revoked on a best-effort basis when the portal knows the person's GitHub username; verify repository access separately when removing someone from sensitive work.

10. Recovery and publishing setup

During first setup, use Fix publishing setup when the wizard says a protected connection needs attention. On the full details page, the same recovery appears as Repair Publishing Setup. Repair refreshes portal-managed GitHub secrets, Azure connection settings, and federated credentials for that app.

Repair does not delete the repository or Azure app, and it does not start a deployment. When repair finishes, select Publish to Azure separately if you want to deploy code. Preparation failures use Try preparation again with the saved safe method; publishing failures use Try publishing again. If a repeated failure has no safe action, use the displayed support reference.

11. Delete an app carefully

Deletion is divided into separate scopes:

Azure deletion does not remove Cedarville's shared App Service Plan or shared PostgreSQL server. If you delete only the portal record and leave GitHub or Azure unchecked, those resources remain but can no longer be managed from My Apps. Arrange manual cleanup with Cedarville IT if that happens.

Before deleting, confirm the app name, decide whether the code or data must be retained, and coordinate with collaborators. Repository and Azure deletion can be difficult or impossible to reverse.

12. Getting help

Start with Troubleshooting, then review the FAQ. If you still need help, contact Cedarville IT using the approved support channel.

Provide the app name, support reference if shown, approximate time, action you selected, exact on-screen message, and a screenshot with sensitive values hidden.

Do not provide passwords, client secrets, database connection strings, environment-variable values, private keys, or downloaded app source unless support specifically arranges a secure transfer.