Move 4 Python Services to GitHub
Budget / Salary$30–40
TypeFreelance project
LocationRemote
Posted2 hours ago
ABOUT US
We are a small automation business with four working Python services, each running in Docker. The code currently exists in only one place, without version history or a reliable backup.
We want to organize it properly in GitHub before building anything new.
We are not programmers. Clear, plain-English documentation matters as much as the technical work.
SCOPE OF WORK
We will provide the source code directly. No production-server access or live credentials are required.
You will:
Create four private repositories in our GitHub organization—one for each service.
Organize each service into a clean, sensible structure.
Add the correct .gitignore, dependency files, Docker files, and an .env.example with placeholders.
Check for passwords, tokens, API keys, .env files, and other sensitive information before creating the first Git commit.
Build and test each service from a fresh clone.
Write a plain-English README for each repository.
Deliver one short handover guide.
We are not requesting new features, major code changes, or production deployment. If a small correction is needed, explain it before making the change.
README REQUIREMENTS
Each README should explain:
What the service does
What information it receives and produces
What software, accounts, or external services it needs
Which configuration values are required
How to download, configure, build, start, and stop it
How to view logs and confirm it is working
Common problems and what to check
What the main files and folders are for
We should be able to follow the instructions without calling the freelancer for help.
HANDOVER GUIDE
The handover guide should explain:
Where the repositories are and what each contains
How to give or remove GitHub access
How future code changes should be saved
Where credentials should be stored
What should never be uploaded to GitHub
How to download a fresh copy and make a basic backup
SECURITY
We will remove all known credentials before sharing the code.
You will perform a second check before the first Git commit and a final secret scan before delivery. If you find a possible secret, stop and tell us where it appears without copying its value into a message, document, or Git history.
DELIVERY AND ACCEPTANCE
Each Docker image must build successfully from a fresh clone without Docker, Python, dependency, file-path, or configuration errors.
If a service requires a live credential to start—such as our Telegram bot—a clear credential-related error is acceptable.
We will add our credentials and test live operation within five working days of delivery. Repository, Docker, file-organization, or documentation problems reported during that period should be corrected before acceptance. Problems caused by our credentials or third-party services are outside the correction scope.
If we report no repository-related problems within five working days, the project will be considered accepted.
REQUIRED SKILLS
Git and GitHub
Python
Docker
Linux basics
Technical writing
TO APPLY
Please answer these questions:
Share a README or technical guide you wrote for nontechnical users. A public link or redacted sample is fine.
How would you prevent secrets from entering the repositories or Git history?
Tell us about something useful you built or improved that nobody asked you to build.
Provide your fixed-price quote and delivery time.
Generic proposals that do not answer the questions will not be considered.
We are a small automation business with four working Python services, each running in Docker. The code currently exists in only one place, without version history or a reliable backup.
We want to organize it properly in GitHub before building anything new.
We are not programmers. Clear, plain-English documentation matters as much as the technical work.
SCOPE OF WORK
We will provide the source code directly. No production-server access or live credentials are required.
You will:
Create four private repositories in our GitHub organization—one for each service.
Organize each service into a clean, sensible structure.
Add the correct .gitignore, dependency files, Docker files, and an .env.example with placeholders.
Check for passwords, tokens, API keys, .env files, and other sensitive information before creating the first Git commit.
Build and test each service from a fresh clone.
Write a plain-English README for each repository.
Deliver one short handover guide.
We are not requesting new features, major code changes, or production deployment. If a small correction is needed, explain it before making the change.
README REQUIREMENTS
Each README should explain:
What the service does
What information it receives and produces
What software, accounts, or external services it needs
Which configuration values are required
How to download, configure, build, start, and stop it
How to view logs and confirm it is working
Common problems and what to check
What the main files and folders are for
We should be able to follow the instructions without calling the freelancer for help.
HANDOVER GUIDE
The handover guide should explain:
Where the repositories are and what each contains
How to give or remove GitHub access
How future code changes should be saved
Where credentials should be stored
What should never be uploaded to GitHub
How to download a fresh copy and make a basic backup
SECURITY
We will remove all known credentials before sharing the code.
You will perform a second check before the first Git commit and a final secret scan before delivery. If you find a possible secret, stop and tell us where it appears without copying its value into a message, document, or Git history.
DELIVERY AND ACCEPTANCE
Each Docker image must build successfully from a fresh clone without Docker, Python, dependency, file-path, or configuration errors.
If a service requires a live credential to start—such as our Telegram bot—a clear credential-related error is acceptable.
We will add our credentials and test live operation within five working days of delivery. Repository, Docker, file-organization, or documentation problems reported during that period should be corrected before acceptance. Problems caused by our credentials or third-party services are outside the correction scope.
If we report no repository-related problems within five working days, the project will be considered accepted.
REQUIRED SKILLS
Git and GitHub
Python
Docker
Linux basics
Technical writing
TO APPLY
Please answer these questions:
Share a README or technical guide you wrote for nontechnical users. A public link or redacted sample is fine.
How would you prevent secrets from entering the repositories or Git history?
Tell us about something useful you built or improved that nobody asked you to build.
Provide your fixed-price quote and delivery time.
Generic proposals that do not answer the questions will not be considered.
Apply on Freelancer →
Project sourced from Freelancer.com. Applications happen directly on the original platform — we never collect your data.