Rethinking My Deploy Now Workshop at OwlHacks
Another successful OwlHacks in the books! After returning as a Night Owl, judging the Health and HCI track, and teaching the Deploy Now Workshop for a second time, I want to take a moment to reflect on workshop development: what really matters, and what makes a workshop a good workshop.
Revising this workshop made me reconsider some of my assumptions about that. I had initially wanted to give students a substantial application with plenty to learn from. This time, I used a much smaller example and focused on helping them get something online that they could use during the hackathon. Hearing how students applied the material to their own projects helped me think more carefully about which learning goals belonged in the workshop and which deserved their own time.
Why Teach Deployment in a Workshop?
The need for this workshop comes from my experience teaching capstone. Students can be comfortable writing code and still have little experience making an application available outside their own development environment. Learning deployment while also managing a substantial team project adds another unfamiliar task to an already demanding course. I would like students to arrive with some experience they can draw on, even if they are not yet comfortable with every part of the process.
There is also a practical reason to teach this earlier. By the time students leave the program, they need to be able to show their work to people who will not clone a repository and configure a development environment to see it. A working application gives others a way to engage with what they have built. At a hackathon, that need is immediate: students want other participants and judges to try their projects, not just hear a description of them.
That made OwlHacks a useful setting for revisiting the lesson. Deployment was not a skill students might need in a later course. It was something they could use that same evening.
Choosing the Example
One of the hardest design decisions was how to make the workshop applicable to students building very different projects. I did not want to teach a procedure that only worked for the example in front of them. Docker seemed like a useful common starting point, but a genuinely project-agnostic deployment strategy is difficult to teach. Applications have different dependencies, storage needs, and assumptions about where they run. Packaging them in containers does not remove those differences.
In the original workshop, I worried that deploying a static website would be too easy and too limited to help with students' actual projects. I deliberately chose something more substantial. Laravel offered a batteries-included architecture, and the application had a database already configured, testing in place, and quality code students could learn from. I wanted them to see how those pieces fit together in a robust application, not just how to put a page online.
Those were worthwhile things to expose students to, but they brought prerequisites into the session. Understanding enough of the application to work with it required explaining the framework. For a while, the workshop became an introduction to Laravel, which was not especially relatable to students using other tools. The problem was not that the example lacked educational value; it was that I had asked it to serve too many educational purposes at once.
There was another problem with my idea of a realistic example. The deployment workflow I had constructed was not necessarily how I would choose to deploy a Laravel application. Laravel Cloud and other managed services handle much of that infrastructure work. Dockerizing Laravel was a valid technical choice, but the extra complexity did not automatically make it a more authentic or useful teaching example.
The hosting setup added another layer of complexity. My original plan was to run students' containers on a DigitalOcean VPS and assign everyone a subdomain. That required setting up a reverse proxy to route requests to the right containers, along with the other IT work involved in managing the server and student addresses. I was not prepared to handle that operational workload alongside a hackathon demonstration workshop. It became overwhelming for me, too. I was not aware of Render when I designed that first version, so I had taken on hosting responsibilities that a managed service could handle.
I was trying to balance realism with applicability across projects. Looking back, the example had become a distraction from both. Students were learning details specific to my chosen framework without necessarily seeing a deployment process they would use for their own work.
What I Changed
For the second version, I replaced Laravel with a minimal Express application. Most of what students initially saw and edited was a static page, but it was still served by a running application. They could add a route or experiment with server-side logic if they wanted to. They did not need to learn Express to complete the deployment.
Simplified deployment paths. The original design required me to manage a shared VPS and assign student subdomains. In the revised workshop, Render handled hosting and public URLs, while a smaller application kept the lesson focused on Docker deployment.
I also narrowed the goal. I wanted students to experience how straightforward it could be to deploy a Docker application to the cloud. Using Render and the provided Docker setup, they could get the application running as a web service, open its public URL, make a change, and see it redeploy. I no longer needed to manage a shared VPS or assign each student a subdomain. The more detailed material on Docker and running the application locally came afterward.
Switching to Render simplified the teaching as well as the hosting. Reverse proxies and server administration are worthwhile topics, but they were not what I wanted students to learn in this session. With that work handled by the platform, there were fewer infrastructure details to explain or troubleshoot, and I could concentrate on helping students connect a change in their code to a change in their live application.
That first success gave students something concrete to connect the later explanations to. More importantly, I hoped it would make them ask, "How does this translate to my app?" I could not anticipate every project through one elaborate example. I could give students a manageable starting point and help them recognize deployment as something they could attempt with their own work.
What I Took From the Experience
Hearing students tell me they had used the workshop material to deploy their hackathon projects was especially exciting. This was what I had worried a simpler example would fail to support, and students were already doing it. Completing a guided exercise is one thing; recognizing that something from it can help with a project of your own is another. Those conversations meant more to me than simply seeing the example application run.
I would not take a successful deployment as evidence that a student now understands all of Docker or can troubleshoot an unfamiliar hosting environment. There is more teaching to do there. But students had a starting point they could use, and some were already carrying it into their own work. That was the outcome I had hoped the revision would support.
The experience made me reevaluate what is important in a workshop. I had tried to teach deployment, expose students to a robust application architecture, and make the lesson applicable across projects in the same session. What mattered more here was whether students left able to deploy something, with enough confidence and curiosity to try it again in their own projects. The architecture, testing, and code-quality goals still mattered, but they did not all need to be part of this introduction to deployment.
That changed how I thought about what to include. Leaving out framework details was not a compromise I needed to make up for with more content elsewhere; it gave students more time to work with the idea I wanted to teach. For future workshops, I want to be clearer about what participants should leave able to do and use that to decide what belongs in the session. I also want to pay attention to where they need help afterward, especially when their own projects introduce dependencies or configuration that the example does not cover.
I ❤️ OwlHacks 🦉
Returning as a Night Owl and judging the Health and HCI track let me stay connected to students' work beyond the workshop itself. I am usually exhausted by the end of the night, so seeing projects I had watched develop reach their final form was a rare treat. I am grateful to the student-led OwlHacks team for creating a setting where students can try something unfamiliar, ask for help, and put what they learn to use so quickly.
The Deploy Now Workshop materials are available on GitHub, including the initial Render deployment, the edit-and-redeploy exercise, and the follow-up Docker lab.