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.

Website: https://studentprojectlab.com

Documentation: https://docs.studentprojectlab.com

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. Submission does not guarantee publication.

1. How Publication Works

The publication process consists of six stages:

Develop: Complete your application in a Git repository.
Prepare: Configure your project for containerized deployment and document its requirements.
Test: Verify that your application builds, runs, and passes the required security checks.
Submit: Identify an exact release candidate and request a security review.
Review: Address any findings identified during faculty review.
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.

GitHub Classroom is not required.

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: