For random toy projects, spinning up a whole Kubernetes cluster is absolutely overkill (unless part of the project is learning Kubernetes). The thing is as you get further along, for some applications, it becomes harder and harder to move to a container-based design as you have to unwind all the weird dependency mappings. I've got an app I've been involved with containerizing for a client at work, and they're dead set on sticking with an Ubuntu 14.04 base container, because they legitimately don't know if it'll even function on a more modern base, and don't feel they can spare the development cycles to figure it out. Thing is, it started as a toy application, deployed to a server by manually SSHing in and doing a git pull from the repo (not even rsync!) and restarting all the services, and that's still how it's deployed in production today.
Containers (and thus Kubernetes) aren't the magical solution to every problem in the world. But they help, and the earlier you can get to an automated, consistent build/deploy process with anything that'll actually serve real customers, the better off you are. Personally, I'd rather design with containers in mind from day one, because it's what I'm comfortable with. There's nothing wrong with deploying code as a serverless-style payload, or even running on a standalone VM, but you need to start planning for how something should work in the real world as early as you can reasonably.
FWIW, cedar-14 stack is Ubuntu 14.04 and that's been the base of Deis Workflow (now Hephy Workflow) for years. We've been meaning to upgrade to Heroku-16 stack (and eventually Heroku-18) but our resources are limited too, and we've had to fight other dragons like getting a website together, and figuring out the build system. (Deis Workflow was EOL'ed last year, and Team Hephy is the fork/continuation of development, which we can do because Deis developers were all gracious enough to keep everything OSS.)
So, back to the point, I'm sure you couldn't deploy your app on Heroku if that's your requirement (because cedar-14 is deprecated, and not available for new deployments anymore) but if you seriously wanted to try containerizing it onto Kubernetes, and if you don't have other obstacles to 12-factor design that you're also not prepared to tackle, then Hephy Workflow v2.19.4 might actually work for you.
Containers (and thus Kubernetes) aren't the magical solution to every problem in the world. But they help, and the earlier you can get to an automated, consistent build/deploy process with anything that'll actually serve real customers, the better off you are. Personally, I'd rather design with containers in mind from day one, because it's what I'm comfortable with. There's nothing wrong with deploying code as a serverless-style payload, or even running on a standalone VM, but you need to start planning for how something should work in the real world as early as you can reasonably.