Student Project Lab: Student Publication Guide

Overview

Student Project Lab provides hosting for approved student-developed software projects. The platform allows students to publish working applications that can be shared with employers, included in professional portfolios, or demonstrated as academic accomplishments.

Publication is available for eligible capstone projects, course projects, independent studies, research projects, and other approved student-developed applications.

Hosting is provided at the department's discretion. 

1. How Publication Works

The publication process consists of six stages:

1. Develop: Complete your application in a Git repository.

2. Prepare: Configure your project for containerized deployment and document its requirements.

3. Test: Verify that your application builds, runs, and passes the required security checks.

4. Submit: Identify an exact release candidate and request a security review.

5. Review: Address any findings identified during faculty review.

6. Publish: Once approved, the department deploys the approved version to Student Project Lab.

Students are responsible for preparing their applications. Department administrators are responsible for production deployment, infrastructure management, and hosting authorization.

You will not receive SSH access to the production server or administrative access to the deployment platform.

2. Source Control Requirements

All applications must be maintained in a Git repository accessible to the department.

GitHub is the preferred hosting provider.

Your repository may be:

• A personal GitHub repository.

• A team-owned repository.

• A GitHub Classroom repository.

• Another Git repository approved by the department.

Repository requirements

Your repository must:

• Contain the complete source code needed to build the application.

• Include a README with installation and development instructions.

• Include deployment configuration and dependency information.

• Have no secrets, credentials, or private keys committed to Git history.

• Use versioned commits and release tags.

• Grant reviewers read access to source code and release information.

• Have an appropriate license or documented permission for third-party source code and assets.

Private repositories are permitted, provided the department can access them through an approved integration.

Recommended repository layout

A typical application might use:

my-project/
├── .github/
│   └── workflows/
│       └── ci.yml
├── frontend/
│   ├── Dockerfile
│   └── ...
├── backend/
│   ├── Dockerfile
│   └── ...
├── compose.yaml
├── .dockerignore
├── .gitignore
├── .env.example
├── README.md
└── DEPLOYMENT.md

The exact structure may differ by framework. Not every application requires a frontend, backend, or database.

3. Containerization Requirements

Student Project Lab uses Docker to host applications.

Your application must be deployable using Docker Compose unless the department explicitly approves another deployment method.

Dockerfile

Each custom application image must have a working Dockerfile.

Your Dockerfile should:

• Use an appropriate maintained base image.

• Install the dependencies required by the application.

• Configure a suitable production startup command.

• Exclude unnecessary build tools and development dependencies from the final image where practical.

• Run the application as a non-root user wherever feasible.

• Avoid including passwords, API keys, or other secrets.

• Build without requiring interactive user input.

Docker Compose

Your repository must include a compose.yaml file defining the services required to operate your application.

For a basic web application listening on port 8000, an example is:

services:
  web:
    build:
      context: .
      dockerfile: Dockerfile

    restart: unless-stopped

    environment:
      APP_ENV: production
      SECRET_KEY: ${SECRET_KEY:?Required}

    expose:
      - "8000"

    healthcheck:
      test:
        - CMD
        - python
        - -c
        - "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8000/health', timeout=3)"
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 30s

This example assumes a Python application with a /health endpoint. Adjust the health check and startup behavior for your framework.

Your application must listen on the configured port and bind to 0.0.0.0, not only 127.0.0.1.

Coolify handles public HTTPS and domain routing. Do not configure a separate public-facing reverse proxy unless it is required and explicitly approved.

Multiple services

Applications may use supporting services, such as:

• PostgreSQL or MariaDB.

• Redis.

• Background workers.

• Other approved components.

Internal services must communicate over private container networks. Databases and other internal services must not expose public host ports.

Use persistent Docker volumes for data that must survive container replacement.

Local testing

Before submission, confirm that your application runs using Docker Compose with a local environment configuration:

docker compose config
docker compose up --build -d
docker compose ps

Inspect application logs:

docker compose logs --tail=100

Stop the application when finished:

docker compose down

Do not use docker compose down -v if you need to preserve local database or application data.

A locally successful deployment does not guarantee approval, but applications that cannot build and run locally will not be accepted for review.

4. Environment Variables and Secrets

Applications must support production configuration without modifying source code.

Use environment variables or another approved secrets mechanism for values such as:

• Database credentials.

• Application encryption keys.

• Session signing secrets.

• Third-party API credentials.

• SMTP passwords.

• Production configuration settings.

Include an .env.example file showing the required variable names.

Example:

APP_ENV=production
SECRET_KEY=
DATABASE_URL=

Never commit a real .env file containing credentials.

The department will configure approved production secrets using the hosting platform.

Do not include production passwords or other secrets in documentation, screenshots, review requests, or GitHub issues.

5. Application Requirements

Your application must:

• Start without interactive input.

• Use a suitable production server rather than a development server.

• Run with debugging disabled.

• Provide a reliable HTTP health-check endpoint.

• Handle application restarts without manual intervention.

• Store persistent data outside replaceable application containers.

• Record operational errors without logging sensitive information.

• Use the externally configured production domain correctly.

• Work behind an HTTPS-terminating reverse proxy.

• Fail safely when required configuration is missing.

Applications that require special infrastructure, hardware, privileged containers, or unusually large resources must receive prior approval.

6. Required Documentation

Include a README.md and a DEPLOYMENT.md file.

README.md

Describe:

• Project name and purpose.

• Student contributors.

• Major technologies and frameworks.

• Principal application features.

• Local installation and development instructions.

• Build and test instructions.

• Any third-party software, assets, or services.

DEPLOYMENT.md

Describe:

1. Required containers and services.

2. Application ports and HTTP endpoints.

3. Required environment variables, without secret values.

4. Database setup and migration procedures.

5. Required persistent storage.

6. Startup and health-check behavior.

7. External API or network access requirements.

8. Initial configuration or administrative setup.

9. Backup and restoration considerations.

10. Known limitations and deployment risks.

A reviewer or administrator should be able to understand how the application runs without contacting you for basic setup instructions.

7. Preparing a Release Candidate

Publication is based on a specific Git commit rather than whichever code happens to be in your repository.

Before requesting review:

1. Commit all changes.

2. Push the intended version to your remote repository.

3. Verify tests and local deployment.

4. Create an annotated release-candidate tag.

For your first release:

git tag -a v1.0.0-rc.1 -m "Publication review candidate"
git push origin v1.0.0-rc.1

Find the associated commit:

git rev-parse v1.0.0-rc.1^{commit}

Submit the full commit SHA and tag in your review request.

Do not move or replace a submitted tag. If changes are required, create a new commit and a new candidate tag, such as v1.0.0-rc.2.

Do not assume that pushing a tag will deploy the application. Only approved releases are authorized for production.

8. Publication and Updates

After a release passes security review, the department may approve the commit as a production release, such as v1.0.0, and publish it at an assigned Student Project Lab subdomain.

Example:

inventory.studentprojectlab.com

Updates to published applications require a new release candidate and approval. The level of review may depend on the changes being introduced.

Minor documentation updates may need less review than changes to authentication, database handling, file uploads, or application dependencies.

The department may suspend, remove, or decline an application if it introduces security, legal, operational, or resource concerns.

9. Hosting Responsibilities

Students are responsible for the correctness, security, and maintainability of their application code.

The department manages the production infrastructure, domains, HTTPS, deployment authorization, and approved hosting configurations.

Students must not assume indefinite hosting. Applications may be retired after the approved hosting period, and extensions require departmental authorization.

Students should maintain independent copies of their source code and any project data they are authorized to retain.

10. Publication Checklist

Before requesting a security review, confirm:

• My repository is accessible to reviewers.

• The intended version is committed and tagged.

• My Dockerfile builds successfully.

• My Docker Compose configuration starts the application.

• My application can run with production-style settings.

• All required configuration variables are documented.

• No credentials or sensitive information are committed.

• Databases and internal services are not publicly exposed.

• The application has a functioning health check.

• Persistent data uses appropriate storage.

• My README and deployment instructions are complete.

• I have reviewed the Application Security Requirements.

• I have tested my application and documented known issues.

Next: Read the Application Security Requirements, then follow the procedure in Requesting Security Review and Publication.