Running and open-sourcing a small app on DigitalOcean with Git

Question

I keep most of my side projects on DigitalOcean, and a while back I built a small one to show a friend how the pieces fit together: upload an image, store it in a Spaces bucket, list it back in a grid. It’s Flask, about 120 lines, no Dockerfile. It deploys to App Platform when I push to Git, and that’s the whole ceremony.

Once it worked I did the obvious next thing and put it on GitHub under an MIT license: oceanforge/spaces-gallery. What I want to walk through here isn’t the app itself, but how little it took to go from “a script on my laptop” to “a project other people can run, fork, and send patches to.” If you’ve been meaning to open-source something small and keep putting it off, this is mostly a note that the tooling is already on your side.

KFSys · Accepted Answer

## The open-sourcing part is just Git There’s no separate “make it open source” step. It’s the same Git commands you already use: git init, commit, push to a public GitHub repo. That’s the code out in the world. Add a LICENSE file so people know they’re allowed to use it. One file. Open a few issues describing things the app is missing. Tag the approachable ones good first issue. That’s it. From that point on, everything runs on Git primitives anyone can use: someone forks the repo, makes a branch, opens a pull request. GitHub Actions runs the checks on that PR automatically. When a change is good, it merges. When enough has piled up, you tag a version and cut a release. Nobody needs commit access, nobody needs a meeting — a fork and a PR is the entire protocol, and it’s the same one used by projects a thousand times this size. ## Why DigitalOcean makes this easy specifically The part that usually kills a small open-source project isn’t Git, though. It’s that a contributor can’t easily run the thing to test their change. That’s where the hosting choice quietly matters. App Platform builds a contributor’s fork the same way it builds mine: connect a repo, it detects Python, installs the requirements, and runs it. No Dockerfile to keep in sync, no build config to explain in the README. And because it’s connected to Git, every push redeploys on its own — the deploy step is just git push, for me and for anyone who forks it. Storage is the same story. Spaces speaks the S3 API, so there’s no proprietary SDK for a contributor to learn before they can help. The upshot is that the setup instructions fit in a paragraph: clone the repo, set four environment variables, run python app.py. A contributor sees exactly what I see, without standing up any infrastructure. When helping is that cheap, people actually help. ## What that added up to I left the repo alone with a handful of small issues, and over about a week contributors I’d never met turned it into something real: Upload validation with clear error messages. A delete button on each image, wired to remove the object from Spaces. Pagination, so a full bucket doesn’t render one giant page. Thumbnails generated with Pillow on upload. A copy-URL button, an image count in the header, an empty-state screen with a favicon. A pytest suite that runs in CI. That’s five releases, v0.1.0 through v0.4.0, most of the work coming through ordinary pull requests. A couple were somebody’s first open-source contribution. None of it required anything more exotic than Git and a stack that any of them could run locally. ## You can lift the Spaces part into your own app One practical takeaway: the code that talks to Spaces is worth stealing on its own. It’s not a library, but the reusable core is about forty lines, and it drops into any Python app that needs user uploads. The one thing to get right is the endpoint, because the panel shows you a URL that boto3 doesn’t want: # The panel shows https://..digitaloceanspaces.com. # boto3 wants the REGION endpoint and adds the bucket itself: endpoint = f"https://{region}.digitaloceanspaces.com" client = boto3.session.Session().client( "s3", region_name=region, endpoint_url=endpoint, aws_access_key_id=key, aws_secret_access_key=secret, config=Config(signature_version="s3v4"), ) After that it’s the S3 API you already know: put_object with ACL="public-read" to make an image loadable in a browser (buckets are private by default), list_objects_v2 to read them back, a few lines of Pillow for thumbnails. ## Try it The repo is github.com/oceanforge/spaces-gallery . It runs on App Platform’s trial credit, it’s MIT, and there are still good first issues open — a download button, configurable upload limits, Cache-Control headers for the CDN, a JSON API, a lightbox. If you want a small, working reference for “images on Spaces,” or a friendly repo to make a first contribution against, it’s right there. The point I’d leave you with: open-sourcing a small app is much less work than it sounds. Git handles the collaboration, App Platform handles the “does it run on someone else’s machine,” and you’re left with the fun part — building the thing.

Bobby · Answer

Hi there, This is a great example of how little it actually takes to ship something real on DigitalOcean. Flask plus App Platform plus Spaces is genuinely one of the tightest stacks for a project like this, no infra to babysit, deploys on push, and the Spaces SDK is straightforward enough that the whole thing fits in 120 lines. The open source angle is worth highlighting too. MIT license, a clean README, and a working deploy target makes it way easier for people to actually run your project rather than just read it. Nice work putting it out there.

alexdo · Answer

Heya, nice writeup, the App Platform auto-build-from-fork point is a genuinely underrated benefit for open source specifically. One thing worth flagging now that this has real contributors and real cloud infrastructure attached. Once a repo takes outside PRs, any CI step that touches your Spaces credentials or App Platform deploy needs to not run with real secrets against untrusted code, a malicious or just careless PR could otherwise exfiltrate keys through a workflow that runs on pull_request against a fork. GitHub Actions treats secrets as unavailable by default on workflows triggered from fork PRs for exactly this reason, worth keeping it that way rather than working around it, and reserving actual deploys for merges to main rather than the PR branch itself. Worth a line in the CONTRIBUTING file too so nobody’s surprised their PR doesn’t get a live preview automatically. Regards

Become a contributor for community

DigitalOcean Documentation

Resources for startups and AI-native businesses

The developer cloud

Start building today

Report this

Running and open-sourcing a small app on DigitalOcean with Git

Related questions

Presigned URLs vs. Spaces CDN — can I get both private access and edge caching?

How to setup ssl for Spaces CDN

How to Offload Static Assets to DigitalOcean Spaces

CDN Bandwidth Usage for Cache Hits on Spaces (S3-Compatible Storage)

CDN Bandwidth Usage for Cache Hits on Spaces

Intermittent 500/502 from CDN while origin returns 200 on mp3 requests

Intermittent 500/502 from CDN while origin returns 200 on mp3 requests

CORS header ‘Access-Control-Allow-Origin’ missing

Does Spaces support HeadObject (AWS Go SDK)?

Random Spaces Error

DO Space CORS Issue For Custom File Formats

Allow object operations only under a certain prefix inside a DO Space

Report this

Running and open-sourcing a small app on DigitalOcean with Git

Related questions

Presigned URLs vs. Spaces CDN — can I get both private access and edge caching?

How to setup ssl for Spaces CDN

How to Offload Static Assets to DigitalOcean Spaces

CDN Bandwidth Usage for Cache Hits on Spaces (S3-Compatible Storage)

CDN Bandwidth Usage for Cache Hits on Spaces

Intermittent 500/502 from CDN while origin returns 200 on mp3 requests

Intermittent 500/502 from CDN while origin returns 200 on mp3 requests

CORS header ‘Access-Control-Allow-Origin’ missing

Does Spaces support HeadObject (AWS Go SDK)?

Random Spaces Error

DO Space CORS Issue For Custom File Formats

Allow object operations only under a certain prefix inside a DO Space