Mandsaur University Students: Deploying a Python API for the First Time on a Free Tier

You can deploy a first Python API on a free tier in an afternoon if you do five things in order: pin your dependencies in a requirements file, read every setting from environment variables, run the app with a production process command, test the live URL with a short smoke test, and keep a rollback path ready before you share the link. This runbook walks through each step and ends with a troubleshooting table for the failures first-time deployers hit most often.

What a free hosting tier actually changes for your API

Free tiers differ between providers and change over time, so treat the following as patterns to check, not promises. Before you pick a platform, open its current pricing or limits page and note the details below.

• Idle behaviour: many free plans put an inactive service to sleep, so the first request after a quiet period can be slow. Your API should still work, but a timeout on the first call is not necessarily a bug.
• Memory and CPU: small allowances mean a heavy machine-learning import can crash the app at startup.
• Disk: files written at runtime, including a SQLite database, may vanish on restart or redeploy. Check whether the platform offers persistent storage.
• Build and run limits: there may be monthly hour caps or build-time limits.
• Databases: a free database may expire or have a small row or storage cap.
• Secrets: the platform should give you a settings page for environment variables. If it does not, choose another platform rather than committing keys to Git.

Choose a platform that can deploy from a GitHub repository, shows build logs, and lets you redeploy an earlier version. Those three features make the rest of this runbook possible.

Pre-deployment checklist for a first Python API

Work through this table on your laptop before you touch a hosting dashboard. Every row catches a failure that is much harder to diagnose remotely.

Runbook step 1: structure the project and freeze the requirements file

Keep the layout flat and boring. The example below is illustrative and was not executed; adapt names to your own project.

notes-api/
  app/
    __init__.py
    main.py
    config.py
  tests/
    test_health.py
  requirements.txt
  .env.example
  .gitignore
  README.md

Your requirements file should list only what the app imports at runtime, with versions. Generate it from the clean virtual environment you tested in, not from a laptop full of unrelated packages.

1. Create a new virtual environment and install only your direct dependencies, for example a web framework and a server.
2. Run the app and its tests.
3. Run pip freeze > requirements.txt in that clean environment.
4. Delete anything that is clearly only for your editor or notebooks.
5. Commit the file and re-test from a second fresh environment.

An illustrative result:

fastapi==0.110.0
uvicorn==0.29.0
pydantic==2.6.4

Version numbers here are placeholders to show the format. Use the versions you actually tested.

Runbook step 2: move every setting into environment variables

Anything that differs between your laptop and the server, or that must stay private, belongs in an environment variable. Typical candidates: database URL, API keys, allowed origins, debug flag, log level.

Commit a .env.example with fake values so you and your reviewers know what is required:

APP_ENV=production
DEBUG=false
DATABASE_URL=sqlite:///./local.db
ALLOWED_ORIGINS=https://your-frontend.example
API_KEY=replace-me

Then read them in one place:

import os

APP_ENV = os.getenv("APP_ENV", "development")
DEBUG = os.getenv("DEBUG", "false").lower() == "true"
DATABASE_URL = os.getenv("DATABASE_URL", "sqlite:///./local.db")
ALLOWED_ORIGINS = os.getenv("ALLOWED_ORIGINS", "").split(",")
API_KEY = os.getenv("API_KEY")

if APP_ENV == "production" and not API_KEY:
    raise RuntimeError("API_KEY is required in production")

The final check makes the app fail loudly at startup if a required variable is missing, which shows up clearly in the build or runtime logs. Enter the real values in the platform’s environment settings page, never in the repository. If a key ever lands in a commit, revoke it and create a new one; deleting the file later does not remove it from Git history.

Runbook step 3: write the process command the platform will run

Locally you may start the app with a development reload flag. The server needs a plain, stable command that binds to all interfaces and to the platform’s port.

# FastAPI (illustrative)
uvicorn app.main:app --host 0.0.0.0 --port $PORT

# Flask (illustrative)
gunicorn app.main:app --bind 0.0.0.0:$PORT --workers 2

• Do not use the reload flag in production.
• On a small free instance, start with one or two workers. More workers use more memory.
• If the platform asks for a Procfile, the line looks like web: uvicorn app.main:app --host 0.0.0.0 --port $PORT. Check the platform’s documentation for the exact file name and syntax it expects.
• The text before the colon in app.main:app is the import path to the module, and the text after it is the variable holding your application object. A mismatch here is the most common cause of “module not found” start-up errors.

Runbook step 4: connect the repository, set the variables, deploy

1. Push your tested code to a GitHub repository.
2. Create a new web service on the platform and select the repository and branch.
3. Set the build command to install from requirements (usually pip install -r requirements.txt).
4. Paste the start command from step 3.
5. Enter each environment variable from your .env.example with real values.
6. Set the Python version if the platform allows it.
7. Trigger the deploy and watch the build log until it says the service is live. Read the log even when it succeeds; warnings about missing packages or ignored settings show up here.

Runbook step 5: a smoke test you can run in under a minute

A smoke test is a handful of requests that prove the deployed app is alive and wired up correctly. It does not replace unit tests. Save this as a script in your repository and run it after every deploy. The script is illustrative and has not been run against any real service.

#!/usr/bin/env bash
BASE_URL="$1"

echo "1. Health check"
curl -s -o /dev/null -w "%{http_code}\n" "$BASE_URL/health"

echo "2. Unknown route should return 404"
curl -s -o /dev/null -w "%{http_code}\n" "$BASE_URL/does-not-exist"

echo "3. Protected route without a key should return 401 or 403"
curl -s -o /dev/null -w "%{http_code}\n" "$BASE_URL/notes"

echo "4. Create and read back with a key"
curl -s -X POST "$BASE_URL/notes" \
  -H "x-api-key: $API_KEY" -H "Content-Type: application/json" \
  -d '{"title":"smoke test"}'
curl -s -H "x-api-key: $API_KEY" "$BASE_URL/notes"

Expected results: 200, 404, 401 or 403, then a created record that appears in the list. If the first request after a quiet period is slow, wait and repeat it before declaring failure, since the free plan may have been idle. Also open the platform’s auto-generated docs page if your framework provides one, and confirm it loads from the public URL.

Worked example: shipping a small notes API from laptop to live URL

This scenario is illustrative, not a real student project. A second-year student builds a notes API with three routes: /health, GET /notes and POST /notes. It works locally.

1. Clean install: in a fresh venv the app fails with “No module named pydantic_settings”. The student had installed it globally. They add it to the requirements file with a version.
2. Variables: the API key was hard-coded. They move it to API_KEY, add .env.example, and enter the real value in the platform settings.
3. Start command: the first deploy fails because the command pointed to main:app while the file is inside the app folder. They change it to app.main:app.
4. Smoke test: health returns 200, but the notes disappear after a redeploy. The app was writing SQLite to the instance’s disk. The student records this limitation in the README and plans a hosted database as a next step.
5. Tag the release: once the smoke test passes, they tag the commit v1.0 so a known-good version exists to return to.

Four problems appeared and none had anything to do with the Python logic. That is typical for a first deployment, and it is why the checklist comes before the dashboard.

Rollback routine: returning to the last working version

Decide how you would undo a bad deploy before you need to.

1. Tag good versions. After each passing smoke test, run git tag v1.1 (or the next number) and push the tag.
2. Use the platform’s redeploy feature. Many dashboards list earlier deploys and let you redeploy one. Check that yours does before relying on it.
3. Otherwise revert in Git. Run git revert <commit> on the bad commit and push, which triggers a new deploy of the previous behaviour.
4. Roll back config separately. If the fault is a changed environment variable, restore the old value. Keep a private note of previous values for non-secret settings.
5. Be careful with data. If a release changed your database schema, code rollback alone may not work. Keep migrations small and reversible, and back up before changing a table.
6. Re-run the smoke test after the rollback and write down what happened.

Troubleshooting table for first-time Python API deployments

A 14-day plan for deploying your first API alongside an internship

If you are doing a two-week programme, this schedule fits a first deployment into the time available. The free two-week online internship from CareerSwami includes an offer letter and a completion certificate after successful completion, and a deployed API with a clear README is a tangible output to show for it.

Mandsaur University internship paperwork and your first deployed API

A deployed project is useful evidence, but at Mandsaur University it sits inside the university’s own internship process. The Internship Guidelines & SOPs booklet (AY 2026-27 template) says the Dean, Principal, HoDs, department internship coordinators and the T&P cell arrange internships after the 2nd, 4th and 6th/7th semesters. It describes industry slots of 4-6 weeks or 120 hours, and a nine-step procedure that includes a joining report and synopsis, weekly mentor review with a daily log, a supervisor evaluation form, a training report and certificate, and a final presentation.

Two practical consequences follow. First, a 14-day online programme is shorter than the booklet’s industry slots, and the booklet’s text does not appear to mention online or virtual internships or credit and marks rules. So do not assume a short online internship satisfies a mandatory requirement. Treat it as skill-building unless your coordinator confirms otherwise in writing. Second, the booklet expects a daily log and mentor review, so the habits in this runbook (tagged releases, a README, a written rollback note) double as a tidy record of your work.

The booklet also says students who arrange training themselves must submit the industry’s confirmation letter to the department internship coordinator and a copy to their mentor. For career support, the placements page describes a Training & Placement Department working with IT and other employers and lists Professor (Dr) Vishal Soni as Training and Placement Officer. BCA students may also notice a Project-work/Apprenticeship line in the 2025 Semester I BCA scheme, listed at 2 credits and 100 marks, so a deployed API could be a candidate project there, subject to your department’s approval.

Verification steps for Mandsaur University students

1. Email your department internship coordinator and ask whether a self-arranged online internship can count towards the mandatory internship, and request the answer in writing.
2. Ask your mentor whether a deployed API and README can serve as the synopsis or report content, and which template (the booklet has a branch-specific cover) applies.
3. Check your own scheme document for your programme and batch to see whether credits or marks are attached to internships or project work.
4. Ask the T&P office which document it wants as proof of any training you complete.
5. Confirm the format of the daily log and the supervisor evaluation form before you start, so you can keep records from day one.

Frequently Asked Questions

Is a free tier good enough for a college project API?

Usually yes, for demos, portfolios and low-traffic coursework. Expect sleeping services, small memory and limited storage. Do not run anything that needs constant uptime or stores data you cannot lose.

Should I use FastAPI or Flask for a first deployment?

Either works. FastAPI gives automatic documentation pages and request validation; Flask is smaller and has a huge body of tutorials. Choose the one you can already build a working local app with, because deployment adds enough new concepts.

Why does my app work locally but fail on the server?

The most common causes are missing requirements, wrong start command path, absent environment variables and a hard-coded port. Compare your clean-venv install and your .env.example against the platform’s build log and settings.

Can I store my data in SQLite on a free tier?

For learning, yes, but many free instances have an ephemeral disk, so the file may reset on restart or redeploy. Check whether the platform offers persistent storage, or use a hosted database and keep its connection string in an environment variable.

What should a smoke test include?

At minimum: a health check, a request for a missing route, a protected route without credentials, and one write followed by one read. Run it after each deployment and keep the script in the repository.

How do I roll back if a deploy breaks the API?

Redeploy an earlier version from the platform’s deploy history if it offers that, or revert the faulty commit in Git and push. Restore any changed environment variable too, then re-run the smoke test. Tagging each good release makes this much faster.

Will deploying an API count towards my university internship requirement?

That depends on your department’s rules, which only your internship coordinator can confirm. Ask in writing whether an online internship or self-built project is accepted, and what proof and format they need.

What should I put in the README for a deployed API?

Include the live URL, a short description, the list of routes, how to run it locally, the environment variables required (without real values), the start command, the known free-tier limits, and how to run the smoke test.

Related Python & Backend Engineering guides

• Rani Rashmoni Green University Students: Common Failures in Short Backend Internships and How to Avoid Them
• KLE Technological University Students: Final-Year Backend Internship Strategy That Leads to Offers
• Mewar University Students: Reading a Legacy Python Codebase on Day One
• All Python & Backend Engineering internship guides