rintaraINSIGHTS

Guide · Application Development

Module 8: Push to GitHub and Deploy the Application

From a local repository to a tested, secure and traceable public URL.

By Rintara14 MIN READIntermediate

A guide to pushing a Python application to GitHub and deploying to Render Free, Railway Free or another provider with migrations, smoke tests and persistence checks.

Learning outcome

After this module, you can prepare a secure repository, push code to GitHub, deploy a Python application to Render or Railway, run database migrations and verify the application after deployment.

Hosting plans can change. Check official pricing and limits before every deployment. Free hosting is suitable for learning, prototypes and demos—it is not automatically suitable for production.

1. Prepare the application before pushing

  • Confirm the application runs and all tests pass locally.
  • List dependencies in requirements.txt.
  • Provide a WSGI entry point such as wsgi:app and use Gunicorn in production.
  • Use environment variables for SECRET_KEY, DATABASE_URL and API keys.
  • Add .env, local databases, uploads and caches to .gitignore.
  • Provide .env.example containing variable names and non-sensitive sample values only.

Minimum .gitignore example

.env
.venv/
venv/
__pycache__/
*.pyc
instance/*.db
instance/uploads/
.pytest_cache/

2. Push the project to GitHub

Create an empty GitHub repository without adding a README or other files if the local project already has Git history. Then run:

git status
git add .
git commit -m "Prepare application for deployment"
git branch --show-current
git remote add origin https://github.com/[ACCOUNT]/[REPOSITORY].git
git push -u origin [BRANCH_NAME]

If the origin remote already exists, inspect it with git remote -v; do not add it twice. The correct commit syntax is git commit -m "message", not git -m commit.

Never push passwords, tokens, API keys, .env files or personal data. If a secret was previously committed, adding it to .gitignore is not enough—revoke or rotate the secret and clean the repository history.

3. Define deployment commands

For a Flask application with the wsgi:app entry point, common settings are:

Build command:
pip install -r requirements.txt

Start command without migration:
gunicorn --config gunicorn.conf.py wsgi:app

Start command that migrates before launching:
/bin/sh -c 'python -m flask --app wsgi:app db upgrade && exec gunicorn --config gunicorn.conf.py wsgi:app'

Use a separate migration or pre-deploy command when the hosting plan supports it. On plans without that feature, the combined shell command can be used for a single-instance application. Do not run migrations concurrently from multiple instances without an appropriate deployment strategy.

4. Deploy to Render Free

  1. In the Render Dashboard, select New → Web Service and connect the GitHub repository.
  2. Select the deployment branch and the Python or Docker runtime matching the project.
  3. Select the Free instance when it is available to your workspace.
  4. Enter the build command, start command and environment variables.
  5. Use PostgreSQL through DATABASE_URL; do not rely on local SQLite for persistent data.
  6. Deploy and review the build, migration and runtime logs.

Important Render Free limits verified on 7 August 2026:

  • A web service spins down after 15 minutes without traffic, and a cold start can take about one minute.
  • The filesystem is ephemeral; SQLite files, uploads and local changes are lost on restart, redeploy or spin-down.
  • Each workspace receives 750 free instance hours per month.
  • Render Postgres Free is limited to 1 GB and expires 30 days after creation.

5. Deploy to Railway Free

  1. Select New Project → Deploy from GitHub Repo and choose the repository.
  2. Confirm Railway detects Python, or define build and start commands manually.
  3. Add environment variables through the Variables tab.
  4. Add PostgreSQL when persistent data is required and use the provided connection URL.
  5. Generate a public domain, deploy, and inspect logs and the health check.

As verified on 7 August 2026, Railway offers a $0 Free plan with $1 of monthly usage credit and a new-user trial with a one-time $5 credit. The Hobby plan is not free: it costs $5 per month and includes $5 of usage credit. Usage beyond credits or plan changes can create charges, so set cost controls and check the pricing page before deployment.

6. Evaluate other free hosting providers

Apply the same checks to any provider:

  • Does it support Python, a web process and PostgreSQL?
  • Does the service sleep, cold-start or have an hour limit?
  • Is the filesystem persistent or ephemeral?
  • How long is a free database retained?
  • Is a payment card required and can spending be capped?
  • Are custom domains, TLS, logs, backups and rollback available?
  • What are the fair-use policy, SLA and production suitability?

7. Test after deployment

  1. Open the home page and health-check endpoint.
  2. Test sign-in, access control and one create/update data flow.
  3. Confirm the database migration version.
  4. Restart or redeploy and confirm data persists.
  5. Check static assets, CSS/JS, time zone and email.
  6. Inspect logs for exposed secrets or personal data.
  7. Record the URL, commit, deployment time, smoke-test results and rollback steps.

Master Prompt Template

Act as a DevOps engineer for a Python application. Audit the repository first and do not push or deploy without my approval.

Repository: [LOCATION]
Framework and entry point: [EXAMPLE: FLASK, WSGI:APP]
Database: [TYPE]
Target platform: [RENDER/RAILWAY/OTHER]
Deployment branch: [BRANCH]

Tasks:
1. Review .gitignore, requirements, entry point, production configuration, migrations and tests.
2. Identify secret or sensitive-data risks without displaying values.
3. List required environment variables.
4. Recommend exact build, migration and start commands.
5. Explain which free-plan limits I must verify in official documentation.
6. Provide GitHub steps from git status through git push using the current branch.
7. Provide platform-specific deployment steps.
8. Provide smoke tests, health checks, persistence checks and rollback.
9. Separate read-only actions, file changes, GitHub pushes and hosting changes.

Request approval before pushing, creating services, changing DNS, running production migrations or exposing the application to the Internet. Never invent secret values and never assume deployment succeeded without checking logs and the live URL.

Practical exercise

Deploy the application to one free platform. Keep evidence of the GitHub commit, successful build, migration version, at least five smoke-test results and one persistence test after restart.

Module completion checklist

  • No secrets or sensitive data are present in the repository.
  • Build, migration and start commands are documented.
  • The application uses a suitable database for persistent data.
  • Platform limits and possible costs are understood.
  • Logs, health checks, smoke tests and rollback were reviewed.
  • The production commit and application version can be identified.

References

  1. GitHub Docs — Adding locally hosted code to GitHub
  2. Render Docs — Deploy for Free
  3. Render Docs — Deploy a Flask App
  4. Railway Docs — Pricing Plans
  5. Railway Docs — Deploy a Flask App