Give your container a good first deployment.

If you already publish a container image, start with a supported public or private registry. If your source lives in GitHub, connect the repository and configure a Dockerfile-based build. Both paths lead to a container artifact — the difference is whether you bring that artifact yourself or ask the platform to build it from a specific source commit.

Know which port your application listens on and set the corresponding application port in the platform. Check your application’s own configuration too: a container that starts successfully can still be unreachable when the port is wrong or the process only listens on a local-only interface. Review application logs after startup — a startup message can help identify the actual listening port.

List the environment variables your application needs to start and the values appropriate to its deployment environment. Separate build-time requirements from runtime requirements so you know at which stage a missing value will cause a problem. Keep secrets out of source code and image layers; configure them through the application configuration workflow, where values are masked and never revealed back to the browser.

iDeployed follows the image’s own runtime user instead of asking you to enter UID/GID values — stock images such as nginx and Redis run unmodified. Your application still needs to work without root privileges: verify it can read its required files and write to any necessary runtime directories. Privileged workloads, host access, unusual kernel requirements and incompatible storage needs remain meaningful boundaries.

Stateless applications are the clearest starting point. If the application writes business data into its container filesystem, use a template or application with persistent storage so data survives container replacement. Remember that persistence is not the same as backup, replication or disaster recovery.

• Grant the GitHub App access to the intended repository.
• Connect the installation to the correct iDeployed project.
• Select the repository and branch.
• Set the Dockerfile path and build context.
• Check the source commit associated with the build request.

Once the image is built, inspect the deployment outcome separately. A successful build proves the image was produced; it does not prove the application is already serving requests.

After deployment, review the observed outcome, active artifact and application logs. These give you a baseline for the next change and make it easier to distinguish configuration problems, build problems and runtime failures later.