"What" goes on the Product Backlog. "How" goes on the Sprint Backlog.
Stories, Tasks, and Implementation Details
The Product Owner never handles anything more granular than a user story. The Product Backlog should never contain tasks or implementation details.
The Sprint Backlog is where tasks live. In Scrum, stories define what functionality should be delivered, not how that functionality is to be implemented. That level of detail is the sole province of the Development Team, who decompose stories into tasks for the Sprint Backlog.
Stories are Project-Related Work
I got (sic) some tasks that I consider story-independent, for example, configuring some stuff in the production environment for a web app.
You are defining stories incorrectly. A user story isn't just a product feature; it's any project-related work above the level of the implementation-specific details. Ideally, a story captures value and deducts from the pool of available team capacity or resources.
In this case, your story should read something like:
As a DevOps engineer,
I need to reconfigure the web application
to reduce its memory footprint for use on small Amazon EC2 instances.
Whether or not this is your actual use case, it clearly shows that what you're calling a "task" is really a legitimate user story that can add value to the project. By placing it on the Product Backlog, you have correctly made this story a visible cost to the project. No invisible work, ever!
"Tasks" should never be created except as a descendant of a Product Backlog item. All tasks on a Sprint Backlog should be traceable to a Product Backlog user story or the Definition of Done. It's never okay to put unrelated tasks on the Sprint Backlog; doing so is a project smell, and generally leads to invisible work or hidden project costs that are kept "off the books."
Just don't do it!